Default Policy question?

Default Policy question?

[Daniel J Walsh]

Has anyone discussed the problem of having root be a member of the 
sysadm_r role.  Is there a way to define policy such that you could
allow a sysadmin to manipulate configuration without allowing them to
effect policy?  Ie, does the default policy allow someone the ability to
change the /etc/printcap file but not run load_policy?  Should we have 
three levels of user by default.  My problem with this is that 
sysadmin's are going to become root and run newrole to sysadm_r to 
manipulate configuration.  If they stay newrole and run a trojaned app,
security is compromized.

user_r    - Very little privs for general users
sysadm_r  - Ability to manipulate all standard Linux config files.
policy_r  - Ability to change the way the kernel handles policy. 
(/etc/security/selinux/*, /etc/grup.conf, chsid, avc_toggle ...)

policy_r should not be defaulted to the root user but garnered in some 
other way.

Anyone have any ideas on this?


Dan


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Stephen Smalley]

On Mon, 2003-06-02 at 12:04, Daniel J Walsh wrote:
> Has anyone discussed the problem of having root be a member of the 
> sysadm_r role.  Is there a way to define policy such that you could
> allow a sysadmin to manipulate configuration without allowing them to
> effect policy?  Ie, does the default policy allow someone the ability to
> change the /etc/printcap file but not run load_policy?  Should we have 
> three levels of user by default.  My problem with this is that 
> sysadmin's are going to become root and run newrole to sysadm_r to 
> manipulate configuration.  If they stay newrole and run a trojaned app,
> security is compromized.
> 
> user_r    - Very little privs for general users
> sysadm_r  - Ability to manipulate all standard Linux config files.
> policy_r  - Ability to change the way the kernel handles policy. 
> (/etc/security/selinux/*, /etc/grup.conf, chsid, avc_toggle ...)
> 
> policy_r should not be defaulted to the root user but garnered in some 
> other way.

The idea of having a separate security administrator has come up before
on the list (see the archives), and was initially explored during the
early stages of the example policy development.  However, separating a
security administrator from the system administrator is difficult unless
you significantly prune what a typical system administrator can do;
otherwise, the system administrator can subvert the software,
configuration or environment of the security administrator and
effectively take control of it.  I'm not saying that it isn't a good
idea, if for no other reason than to guard against carelessness;
splitting up sysadm_r in general would be useful, and limiting sysadm_t
(or its replacements) to executing a small set of trusted code would
likewise be useful.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Tom]

On Mon, Jun 02, 2003 at 12:04:21PM -0400, Daniel J Walsh wrote:
> Has anyone discussed the problem of having root be a member of the 
> sysadm_r role.  

I think it was mentioned on this list, yes. In fact, I've made it a
habit to remove root from sysadm_r.


> Is there a way to define policy such that you could
> allow a sysadmin to manipulate configuration without allowing them to
> effect policy?  Ie, does the default policy allow someone the ability to
> change the /etc/printcap file but not run load_policy?  

Yes, it does. The policy files have their own types, so it would be
easy to restrict them more than normal config files. In fact, many
config files have their own types as well, so you can seperate
different applications and have different admins for them.


> Should we have three levels of user by default.  

More :)

I've just started working on something. I will likely post a proposal
in a couple of days. If you want to work with me on this, just yell.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Default Policy question?

[Frank Mayer]

> user_r    - Very little privs for general users
> sysadm_r  - Ability to manipulate all standard Linux config files.
> policy_r  - Ability to change the way the kernel handles policy.
> (/etc/security/selinux/*, /etc/grup.conf, chsid, avc_toggle ...)
> 
> policy_r should not be defaulted to the root user but garnered in some
> other way.
> 
> Anyone have any ideas on this?

I started down that patch a little last summer.  This resulted in patch
to the policy directory that created separate policies for checkpolicy
and load_policy (before sysadm_r had all the permissions necessary), and
with installing the policy source in a well-known location and labeling
the source files and directories.  Several times we thought about trying
to create a real policy administrator role, but never got to it.  It's a
great idea, but I believe it will be hard to achieve true separation.
Nonetheless, a pragmatic first step is still a useful addition to the
policy.  

We're also exploring a more fundamental policy management infrastructure
enhancement (where the policy becomes a set of separately management and
protected objects), but its only an idea on the drawing board right now
awaiting funding. 

Frank


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Tom]

On Mon, Jun 02, 2003 at 01:21:53PM -0400, Stephen Smalley wrote:
> security administrator from the system administrator is difficult unless
> you significantly prune what a typical system administrator can do;
> otherwise, the system administrator can subvert the software,
> configuration or environment of the security administrator and
> effectively take control of it.  

But if the secadm_r controls the policy, he should have enough power at
his hands to prevent subversion. Things he would have to protect:

* his home directory (environment)
* policy and policy tools
* kernel and kernel modules

Other than that, all other tools are limited by the policy, aren't
they? The sysadm_r can replace ls with a trojaned binary, but he can't
make it do anything that the normal ls isn't allowed to do.


Please tell me if I'm wrong - I'm seing if it's possible to define a
set of "core tools", defined essentially as "access to any of these means 
game over". I'm not sure if I can invert the process and say that _no_
access to any of them means system integrity still valid, but it
appears so.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Russell Coker]

On Tue, 3 Jun 2003 07:03, Tom wrote:
> But if the secadm_r controls the policy, he should have enough power at
> his hands to prevent subversion. Things he would have to protect:
>
> * his home directory (environment)
> * policy and policy tools
> * kernel and kernel modules

So who runs debugfs/fdisk/mkfs?

> Other than that, all other tools are limited by the policy, aren't
> they? The sysadm_r can replace ls with a trojaned binary, but he can't
> make it do anything that the normal ls isn't allowed to do.

When "ls" is run by any userdomain it does not trigger a domain transition.  
If ls is compromised it's game-over, ls can do lots of interesting things 
other than list the stats of files if it wants to...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Tom]

On Tue, Jun 03, 2003 at 09:51:59AM +1000, Russell Coker wrote:
> > * his home directory (environment)
> > * policy and policy tools
> > * kernel and kernel modules
> 
> So who runs debugfs/fdisk/mkfs?

Note that I'm not trying to protect against DESTRUCTION of the system,
but against subversion.


> > Other than that, all other tools are limited by the policy, aren't
> > they? The sysadm_r can replace ls with a trojaned binary, but he can't
> > make it do anything that the normal ls isn't allowed to do.
> 
> When "ls" is run by any userdomain it does not trigger a domain transition.  
> If ls is compromised it's game-over, ls can do lots of interesting things 
> other than list the stats of files if it wants to...

But if I control the policy, I can add an auto_trans rule. bin_exec_t
could auto_trans to sysadm_t so the sysadm gains nothing by trojaning
any binary. :)

I didn't say the default policy is good enough for this. I'm just
trying to figure out whether it's possible at all.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Stephen Smalley]

On Mon, 2003-06-02 at 17:03, Tom wrote:
> But if the secadm_r controls the policy, he should have enough power at
> his hands to prevent subversion. Things he would have to protect:
> 
> * his home directory (environment)
> * policy and policy tools
> * kernel and kernel modules

secadm_r has far more dependencies than that short list.  What happens
if you let sysadm_r set other user's passwords?  What happens if
sysadm_r has any form of raw access to the disk or memory?  What happens
if sysadm_r can upgrade any of the authentication programs (e.g.
/bin/login, /usr/bin/sshd) or any of their dependencies (pam modules,
libc)?  What happens if sysadm_r can upgrade secadm_r's shell?  His
editor?  You get the idea.

> Other than that, all other tools are limited by the policy, aren't
> they? The sysadm_r can replace ls with a trojaned binary, but he can't
> make it do anything that the normal ls isn't allowed to do.

I think you have this backwards. Make secadm_r's initial domain
(secadm_t) unprivileged except for the ability to run authorized policy
management tools in a domain that can modify the policy, and make sure
that all such tools re-authenticate like newrole does in order to ensure
that they are invoked at the request of the user.  Then, it doesn't
matter whether ls runs in secadm_t.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Russell Coker]

On Tue, 3 Jun 2003 16:30, Tom wrote:
> On Tue, Jun 03, 2003 at 09:51:59AM +1000, Russell Coker wrote:
> > > * his home directory (environment)
> > > * policy and policy tools
> > > * kernel and kernel modules
> >
> > So who runs debugfs/fdisk/mkfs?
>
> Note that I'm not trying to protect against DESTRUCTION of the system,
> but against subversion.

mkfs and debugfs can be used for subversion of the system by replacing files.

If you can manage block devices then you can manage almost everything else if 
you try hard enough.  Palladium and TCPA are attempts to change this, but 
AFAIK no-one is working on integrating such technology with SE Linux.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Default Policy question?

[Tom]

On Tue, Jun 03, 2003 at 08:20:44AM -0400, Stephen Smalley wrote:
> secadm_r has far more dependencies than that short list.  What happens
> if you let sysadm_r set other user's passwords?  What happens if
> sysadm_r has any form of raw access to the disk or memory?  What happens
> if sysadm_r can upgrade any of the authentication programs (e.g.
> /bin/login, /usr/bin/sshd) or any of their dependencies (pam modules,
> libc)?  What happens if sysadm_r can upgrade secadm_r's shell?  His
> editor?  You get the idea.

I get it. It seems my "core tools" idea won't work out.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.