From: klondike <franxisco1988@gmail.com>
To: gentoo-hardened@lists.gentoo.org
Subject: Re: [gentoo-hardened] SELinux policy rules principles?
Date: Fri, 21 Jan 2011 23:12:20 +0100 [thread overview]
Message-ID: <4D3A04C4.9010201@gmail.com> (raw)
In-Reply-To: <20110121215509.GA19680@siphos.be>
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
El 21/01/11 22:55, Sven Vermeulen escribió:
> On Sun, Jan 16, 2011 at 11:06:47AM -0600, Chris Richards wrote:
>> On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
>>> When writing security policies, it is important to first have a vision on
>>> how the security policies should be made. Of course, final vision should be
>>> with a systems' security administrator, but a distribution should give a
>>> first start for this.
> [... What to allow ...]
>> My general feeling is that the system should operate FROM THE USER
>> PERSPECTIVE the way it always does, i.e. the existence of SELinux should
>> be relatively transparent to the user and/or administrator, at least to
>> the extent that is practical. There may be some things that you simply
>> can't avoid changing, but they should generally be few and far between.
> [... What to hide ...]
>> My general feeling here is that, again where practical, we should avoid
>> cluttering the logs. Logs that are cluttered with noise don't get
>> properly evaluated for the truly exceptional conditions that the
>> administrator needs to be concerned about. Obviously, there are tools
>> that can help with this, but those tools should be used for the purpose
>> of helping the administrator organize the information, not prune the
>> logs of stuff to ignore. If there's stuff that is going to be routinely
>> ignored because it is essentially useless chatter, then it shouldn't be
>> there to start with.
> Well, I've taken the liberty of writing down a sort-of policy document in
> which we can include our development principles and methods. The idea is
> that both existing and new developers then know how to "include" their
> suggested changes and how to configure/design the added SELinux policy
> rules.
>
> The document: http://goo.gl/2U0Zr
>
> I've included a few of the items we discussed already, but also added
> two others ones (see the "No Role-Specific Domains" and "Only Reference
> Policy Suggested Roles" rules).
>
> It's a *discussion* document, I'm really open to (many) suggestions (and
> enhancements ;-
Recovering the spirit from the good old times huh? That's good to hear ^_^
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-01-21 22:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-16 15:09 [gentoo-hardened] SELinux policy rules principles? Sven Vermeulen
2011-01-16 17:06 ` Chris Richards
2011-01-19 19:39 ` Sven Vermeulen
2011-01-19 20:05 ` Chris Richards
2011-01-19 20:25 ` Sven Vermeulen
2011-01-19 20:34 ` Chris Richards
2011-01-21 21:55 ` Sven Vermeulen
2011-01-21 22:12 ` klondike [this message]
2011-01-21 22:43 ` Chris Richards
[not found] ` <4D33455B.8050708@users.sourceforge.net>
2011-01-19 19:54 ` Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D3A04C4.9010201@gmail.com \
--to=franxisco1988@gmail.com \
--cc=gentoo-hardened@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox