new LSM ver

new LSM ver

[Timothy Wood]

Anyone notice that the default context for root in the new lsm package
is a user_r and not sysadm_r?  Any specific reason for this change or is
it a mistake?

Timothy,


--
You have received this message because you are subscribed to the selinux 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.

poweroff problem?

[Leslie J. French]

I've just installed lsm 2-4 selinux 2002070313 on top of RH7.3 (2.4.18-3)

I never tried on my older version, but I found that /sbin/poweroff doesn't
work under SELinux as I configured/built it.  If I boot into the RH kernel,
it works (turns off the machine power), but in SELinux it shuts down as far
as "Powering off" message but leaves the machine running. In the config I
set:

  ACPI support; APM-enable-at-boot, idle-when-idle and
use-APM-bios-to-poweroff

The system is running [kapmd] and apmd daemons, but I'm wondering if there
is a conflict between the RH and LSM versions, since the boot log shows:

   apm BIOS 1.2
   ....
   Capability LSM initialised
   ACPI: APM is already active, exiting.

And there are a lot of avc violations associated with killall from apmd_t to
various other types (e.g. kernet_t).  This is as "out of the box" as I can
make my system, none of my users or domains are in the system, and I'm using
the .te and .fc files directly from the distribution.

If a more knowledgable person could give me a hint as to what might be going
wrong, I would appreciate it.  If you need the config/log files I will post
them separately.

Thanks,  Leslie


--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Russell Coker]

On Fri, 5 Jul 2002 19:21, Timothy Wood wrote:
> Anyone notice that the default context for root in the new lsm package
> is a user_r and not sysadm_r?  Any specific reason for this change or is
> it a mistake?

I wouldn't expect Steve to make a mistake about such things.

I'm willing to bet that it's related to the recent sshd bugs...

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Stephen Smalley]

On 5 Jul 2002, Timothy Wood wrote:

> Anyone notice that the default context for root in the new lsm package
> is a user_r and not sysadm_r?  Any specific reason for this change or is
> it a mistake?

This is mentioned in the selinux/ChangeLog, so it is a safe bet that it
wasn't a mistake.  As mentioned earlier on the list in discussing the
recent sshd bugs, I removed direct transitions from sshd_t to sysadm_t
from the sshd.te file, thus requiring an explicit newrole.  Hence, it was
only logical to also change the default login context for root to user_r.
This is also simply safer as a default behavior.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Timothy Wood]

В Пнд, 08.07.2002, в 07:24, Stephen Smalley написал: 
> 
> On 5 Jul 2002, Timothy Wood wrote:
> 
> > Anyone notice that the default context for root in the new lsm package
> > is a user_r and not sysadm_r?  Any specific reason for this change or is
> > it a mistake?
> 
> This is mentioned in the selinux/ChangeLog, so it is a safe bet that it

Whoops.  I guess I should read those things more often. 

> wasn't a mistake.  As mentioned earlier on the list in discussing the
> recent sshd bugs, I removed direct transitions from sshd_t to sysadm_t
> from the sshd.te file, thus requiring an explicit newrole.  Hence, it was
> only logical to also change the default login context for root to user_r.
> This is also simply safer as a default behavior.

So what is going ot be done about root permissions and such since you
are restricting them now?  I mean there are just some things you have to
be root and have root permissions to run.  Are you rewriting everything
to run based on security context instead of user?  That would be ideal,
no I take that back, that would be awesome if things would run based on
security context of the user running them.  Then you could get rid of
root altogether.  

Anywho (sorry for the rant) a really good/simple example of the new
default context is this.  Lets say you want to add a new user... oh
wait, you can't!  Why?  No one but root can do this and now, not even
root can't do it.  Did a primary service, such as named, bail out for
some reason?  Too bad!  You do not have any way to restart it except by
rebooting the server.  Same reason, root only.

But don't get me wrong.  Getting rid of root is a good idea but it's too
early in the game to make changes like this.  It pretty much breaks the
system in enforcing mode.

Timothy,


--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Stephen Smalley]

On 8 Jul 2002, Timothy Wood wrote:

> So what is going ot be done about root permissions and such since you
> are restricting them now?  I mean there are just some things you have to
> be root and have root permissions to run.  Are you rewriting everything
> to run based on security context instead of user?  That would be ideal,
> no I take that back, that would be awesome if things would run based on
> security context of the user running them.  Then you could get rid of
> root altogether.
>
> Anywho (sorry for the rant) a really good/simple example of the new
> default context is this.  Lets say you want to add a new user... oh
> wait, you can't!  Why?  No one but root can do this and now, not even
> root can't do it.  Did a primary service, such as named, bail out for
> some reason?  Too bad!  You do not have any way to restart it except by
> rebooting the server.  Same reason, root only.
>
> But don't get me wrong.  Getting rid of root is a good idea but it's too
> early in the game to make changes like this.  It pretty much breaks the
> system in enforcing mode.

I think you've misunderstood what we've done.  We have merely changed the
default login context for root to the user_r role, and prohibited direct
ssh logins in the sysadm_r role.  For administration, you can still login
as yourself, run newrole to change to sysadm_r, and run su to obtain the
Linux root user identity.  Or, you can login as root if you permit direct
root logins and then run newrole to change to sysadm_r.

The change simply ensures that a vulnerability in sshd does not open a
direct path to sysadm_r.  The attacker will not be able to reach sysadm_r
without authenticating to newrole.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Timothy Wood]

В Пнд, 08.07.2002, в 10:39, Stephen Smalley написал:
> 
> On 8 Jul 2002, Timothy Wood wrote:
> 
> > So what is going ot be done about root permissions and such since you
> > are restricting them now?  I mean there are just some things you have to
> > be root and have root permissions to run.  Are you rewriting everything
> > to run based on security context instead of user?  That would be ideal,
> > no I take that back, that would be awesome if things would run based on
> > security context of the user running them.  Then you could get rid of
> > root altogether.
> >
> > Anywho (sorry for the rant) a really good/simple example of the new
> > default context is this.  Lets say you want to add a new user... oh
> > wait, you can't!  Why?  No one but root can do this and now, not even
> > root can't do it.  Did a primary service, such as named, bail out for
> > some reason?  Too bad!  You do not have any way to restart it except by
> > rebooting the server.  Same reason, root only.
> >
> > But don't get me wrong.  Getting rid of root is a good idea but it's too
> > early in the game to make changes like this.  It pretty much breaks the
> > system in enforcing mode.
> 
> I think you've misunderstood what we've done.  We have merely changed the
> default login context for root to the user_r role, and prohibited direct
> ssh logins in the sysadm_r role.  For administration, you can still login
> as yourself, run newrole to change to sysadm_r, and run su to obtain the
> Linux root user identity.  Or, you can login as root if you permit direct
> root logins and then run newrole to change to sysadm_r.
> 
> The change simply ensures that a vulnerability in sshd does not open a
> direct path to sysadm_r.  The attacker will not be able to reach sysadm_r
> without authenticating to newrole.

This is true.  You can also merely change the context when you login (if
you log in as root).  I suppose I jumpped the gun a little there,
however I do like the idea of severely restricting root or removing root
altogether.  Would I be correct in that pretty much everything would
have to be rewritten if this were to be accomplished (the removal of
root, that is)?

Timothy,



--
You have received this message because you are subscribed to the selinux 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: new LSM ver

[Stephen Smalley]

On 8 Jul 2002, Timothy Wood wrote:

> This is true.  You can also merely change the context when you login (if
> you log in as root).

If you login via sshd, you can only login with the default context.  You
can then change contexts via newrole.

> however I do like the idea of severely restricting root or removing root
> altogether.  Would I be correct in that pretty much everything would
> have to be rewritten if this were to be accomplished (the removal of
> root, that is)?

This is simple as far as the kernel is concerned.  You would simply
disable the stacking support in the SELinux module or stack with a null
module so that SELinux would provide the sole authoritative decision for
Linux capabilities (i.e. root privileges).  The difficult tasks would be
updating all of the applications that have hardcoded assumptions about uid
0 or about setuid programs (and don't forget ld.so!), and configuring the
policy appropriately now that you are depending entirely on the
SELinux policy to authorize root privileges.

See http://marc.theaimsgroup.com/?l=selinux&m=97922666422991&w=2 for an
earlier discussion of how SELinux relates to Linux capabilities.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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.