changing root to default to sysadm_r

changing root to default to sysadm_r

[Nick]

I thought I could do make root come up in the sysadm_r initially by
changing the users.te file

diff users .users
42c42
< user root roles { sysadm_r staff_r };
---
> user root roles { staff_r sysadm_r };

and recompiling the policy.

Apparently not, suggestions! and comments why it is not this way
already.

-- 
Nick (Nix) Gray
Senior Systems Engineer
Bruzenak Inc.
(512) 331-7998

--
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: changing root to default to sysadm_r

[forrest whitcher]

Nick

I don't know why you're having problems changing it but I know why
it was/is set this way.

If root defaults to sysadm_r, then certain kinds of sshd exploits
(kinds that _heve_ been seen before) can get the attacker sysadm_r,
game over, not good.

The requirement to authenticate explicitly thru newrole intends to
to avoid this.

forrest




On Wed, 10 Dec 2003 16:51:42 -0600 (unchecked - local sync NTPstrat4)
Nick <nagray@austin.rr.com> did inscribe thusly:

> I thought I could do make root come up in the sysadm_r initially by
> changing the users.te file
> 
> diff users .users
> 42c42
> < user root roles { sysadm_r staff_r };
> ---
> > user root roles { staff_r sysadm_r };
> 
> and recompiling the policy.
> 
> Apparently not, suggestions! and comments why it is not this way
> already.
> 
> -- 
> Nick (Nix) Gray
> Senior Systems Engineer
> Bruzenak Inc.
> (512) 331-7998
> 
> --
> 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.

--
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: changing root to default to sysadm_r

[Russell Coker]

On Thu, 11 Dec 2003 09:51, Nick <nagray@austin.rr.com> wrote:
> I thought I could do make root come up in the sysadm_r initially by
> changing the users.te file
>
> diff users .users
> 42c42
> < user root roles { sysadm_r staff_r };
> ---
>
> > user root roles { staff_r sysadm_r };

As far as I am aware there are no order dependencies at all in the policy 
(Steve, please correct me if I am wrong).

A quick test on my machine shows that the policy database has the same MD5 
checksum regardless of the order of roles in such statements.  But even if 
there was a difference, there is no API for applications to learn about such 
differences.

The way to solve this is to change the order in
/etc/security/default_contexts, change this:
system_r:local_login_t  user_r:user_t staff_r:staff_t sysadm_r:sysadm_t
to this:
system_r:local_login_t  sysadm_r:sysadm_t user_r:user_t staff_r:staff_t

On Thu, 11 Dec 2003 11:04, forrest whitcher <fw@fwsystems.com> wrote:
> If root defaults to sysadm_r, then certain kinds of sshd exploits
> (kinds that _heve_ been seen before) can get the attacker sysadm_r,
> game over, not good.

It's true that we don't want to permit sshd to transition to sysadm_r.  
However I believe that it's OK to permit this from local_login_t for the 
following reasons:
1)  /bin/login code is simpler than sshd code.
2)  /bin/login can only be accessed from system console which prevents entire 
classes of attack.
3)  The standard administration practise is to ssh to servers as non-root and 
then "su" to perform admin tasks, using newrole is a variation on that theme 
and corresponds to expectations of users.  It is standard practise to login 
directly as root at the console, because of this users expect to be able to 
login as sysadm_r at the console.

2 is probably the killer arguement, 1 is important too, 3 is necessary for 
user acceptance (we could have an arguement about whether it makes sense from 
a security POV).

-- 
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: changing root to default to sysadm_r

[Stephen Smalley]

On Wed, 2003-12-10 at 20:18, Russell Coker wrote:
> The way to solve this is to change the order in
> /etc/security/default_contexts, change this:
> system_r:local_login_t  user_r:user_t staff_r:staff_t sysadm_r:sysadm_t
> to this:
> system_r:local_login_t  sysadm_r:sysadm_t user_r:user_t staff_r:staff_t

Alternatively, you should be able to create a /root/.default_contexts
file with this entry to override the system defaults, so that only root
defaults to logging in as sysadm_r, and other users who are authorized
for both staff_r and sysadm_r will still default to staff_r.  You'd have
to make sure that local_login_t can read the /root/.default_contexts
file, either by labeling it with the default_context_t type or by
allowing local_login_t to read sysadm_home_t:file.

-- 
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: changing root to default to sysadm_r

[Nick]

Forrest,

Ssh shouldn't be running in the sysadm_r context. I will have to
research the exploits and figure out what makes sense. The problem here
is that root initially logs into a directory that doesn't match his
context. If you cd to / and try to cd back, you cant get in. That is an
error.

You have to ask yourself, in a secure system what is the purpose of a
root account? for a TOS/CMW it is really for nothing more than
development.


On Wed, 2003-12-10 at 18:03, forrest whitcher wrote:
> Nick
> 
> I don't know why you're having problems changing it but I know why
> it was/is set this way.
> 
> If root defaults to sysadm_r, then certain kinds of sshd exploits
> (kinds that _heve_ been seen before) can get the attacker sysadm_r,
> game over, not good.
> 
> The requirement to authenticate explicitly thru newrole intends to
> to avoid this.
> 
> forrest
> 
> 
> 
> 
> On Wed, 10 Dec 2003 16:51:42 -0600 (unchecked - local sync NTPstrat4)
> Nick <nagray@austin.rr.com> did inscribe thusly:
> 
> > I thought I could do make root come up in the sysadm_r initially by
> > changing the users.te file
> > 
> > diff users .users
> > 42c42
> > < user root roles { sysadm_r staff_r };
> > ---
> > > user root roles { staff_r sysadm_r };
> > 
> > and recompiling the policy.
> > 
> > Apparently not, suggestions! and comments why it is not this way
> > already.
> > 
> > -- 
> > Nick (Nix) Gray
> > Senior Systems Engineer
> > Bruzenak Inc.
> > (512) 331-7998
> > 
> > --
> > 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.
-- 
Nick (Nix) Gray
Senior Systems Engineer
Bruzenak Inc.
(512) 331-7998

--
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.