From: Joshua Brindle <method@manicmethod.com>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Crispin Cowan <crispin@crispincowan.com>,
Andrew Morgan <morgan@kernel.org>,
casey@schaufler-ca.com, Stephen Smalley <sds@tycho.nsa.gov>,
"Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org, chrisw@sous-sol.org,
darwish.07@gmail.com, jmorris@namei.org, paul.moore@hp.com,
LSM List <linux-security-module@vger.kernel.org>
Subject: Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Date: Mon, 26 Nov 2007 14:55:10 -0500 [thread overview]
Message-ID: <474B249E.1050504@manicmethod.com> (raw)
In-Reply-To: <8F9AE768-CCAB-4D14-BEBA-0A19938113BA@mac.com>
Kyle Moffett wrote:
> On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
>> Kyle Moffett wrote:
>>> Actually, a fully-secured strict-mode SELinux system will have no
>>> unconfined_t processes; none of my test systems have any. Generally
>>> "unconfined_t" is used for situations similar to what AppArmor was
>>> designed for, where the only "interesting" security is that of the
>>> daemon (which is properly labelled) and one or more of the users are
>>> unconfined.
>>
>> Interesting. In a Targeted Policy, you do your policy administration
>> from unconfined_t. But how do you administer a Strict Policy machine?
>> I can think of 2 ways:
>
> [snip]
>
>> * there is some type that is tighter than unconfined_t but none the
>> less has sufficient privilege to change policy
>>
>> To me, this would be semantically equivalent to unconfined_t, because
>> any rogue code or user with this type could then fabricate
>> unconfined_t and do what they want
>
> Well, in a strict SELinux system, someone who has been permitted the
> "Security Administrator" role (secadm_r) and who has logged in through
> a "login_t" process may modify and reload the policy. They are also
> permitted to view all files up to their clearance, write files below
> their level, and relabel files. On the other hand, they do not have
> any system-administration privileges (those are reserve for sysadm_r).
>
Ofcourse secadm can give himself privileges to anything he wants, that
isn't necessarily the point though, he is trusted to change the policy.
He is, however, protected from other people: he can't, for example, read
user_home_t files. This protects the integrity of his environment and
the processes he runs. unconfined_t, of course, does not have this
protection.
> Under the default policy the security administrator may disable
> SELinux completely, although that too can be adjusted as "load policy"
> is yet another specialized permission.
>
load policy is pretty course grained, there are ways to make policy
modification privileges more fine grained though such as by using the
policy management server.
next prev parent reply other threads:[~2007-11-26 19:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200711202206.lAKM6BlW025868@imap1.linux-foundation.org>
2007-11-21 15:48 ` + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree Serge E. Hallyn
2007-11-21 15:51 ` Stephen Smalley
2007-11-21 17:04 ` Serge E. Hallyn
2007-11-21 17:21 ` Casey Schaufler
2007-11-21 18:02 ` Stephen Smalley
2007-11-21 19:19 ` Casey Schaufler
2007-11-24 3:25 ` Andrew Morgan
2007-11-24 4:47 ` Casey Schaufler
2007-11-24 6:09 ` Andrew Morgan
2007-11-24 11:39 ` Crispin Cowan
2007-11-24 19:16 ` Casey Schaufler
2007-11-25 2:07 ` Kyle Moffett
2007-11-25 3:36 ` Crispin Cowan
2007-11-26 17:36 ` Kyle Moffett
2007-11-26 19:55 ` Joshua Brindle [this message]
2007-11-24 11:39 ` Crispin Cowan
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=474B249E.1050504@manicmethod.com \
--to=method@manicmethod.com \
--cc=casey@schaufler-ca.com \
--cc=chrisw@sous-sol.org \
--cc=crispin@crispincowan.com \
--cc=darwish.07@gmail.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=paul.moore@hp.com \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
/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