revising the su decision

revising the su decision

[Russell Coker]

Up until now the su program was not modified, so changing to a different UID 
was a separate and independant operation from changing domain via newrole.

However now that the sshd policy has been set to default to not allow logins 
as sysadm_r:sysadm_t this causes some inconveniance.  I have to ssh in to my 
server as a non-root account with a non-sysadm_r context.  Then I have to use 
newrole to change to sysadm_r (entering the password), and then I have to su 
to the root account (entering the root password).

This requires entering the password two times (or three if not using ssh 
authorized_keys).

This is excessively painful, and I think that to make SE Linux more usable we 
need to address this issue, possibly by changing su to allow it to change 
roles too.

What do you think?

-- 
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: revising the su decision

[Simon Han]

Hi Russell,
	I was about to pose the same comment on newrole/su.  :)  I guess
there was some idea behine creating newrole as independent program instead
of extending su.  Could someone share the idea?

Thanks,
Simon

On Fri, 12 Jul 2002, Russell Coker wrote:

> Up until now the su program was not modified, so changing to a different UID 
> was a separate and independant operation from changing domain via newrole.
> 
> However now that the sshd policy has been set to default to not allow logins 
> as sysadm_r:sysadm_t this causes some inconveniance.  I have to ssh in to my 
> server as a non-root account with a non-sysadm_r context.  Then I have to use 
> newrole to change to sysadm_r (entering the password), and then I have to su 
> to the root account (entering the root password).
> 
> This requires entering the password two times (or three if not using ssh 
> authorized_keys).
> 
> This is excessively painful, and I think that to make SE Linux more usable we 
> need to address this issue, possibly by changing su to allow it to change 
> roles too.
> 
> What do you think?
> 
> -- 
> 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.
> 


--
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: revising the su decision

[Stephen Smalley]

On Fri, 12 Jul 2002, Russell Coker wrote:

> However now that the sshd policy has been set to default to not allow logins
> as sysadm_r:sysadm_t this causes some inconveniance.  I have to ssh in to my
> server as a non-root account with a non-sysadm_r context.  Then I have to use
> newrole to change to sysadm_r (entering the password), and then I have to su
> to the root account (entering the root password).
>
> This requires entering the password two times (or three if not using ssh
> authorized_keys).

Which is exactly what we want.  You authenticate to the sshd daemon to
login as the user (authenticate user to sshd).  Then, you re-authenticate
to newrole to verify that the user truly wants to change roles
(authenticate user to newrole to ensure that newrole wasn't called by
malicious code unwittingly run by the user or by a compromised sshd).  You
then use su to assume Linux capabilities (authenticate as root user),
which is orthogonal to the SELinux security context (user, role, and
domain).  This is precisely how I have been using SELinux for a long
time.  Hurdles to remote logins with administrator privileges are a good
thing, IMHO.

Notice that you can still directly ssh into a root account if your
sshd_config permits it and then use newrole -r sysadm_r, avoiding the
separate su step.  This works, although you start off without a home
directory and without having run your dotfiles due to a lack of access to
/root.  However, I don't recommend this approach.

> This is excessively painful, and I think that to make SE Linux more usable we
> need to address this issue, possibly by changing su to allow it to change
> roles too.
>
> What do you think?

I think you need to carefully consider what this would mean.  'su'
authenticates the new user identity to control entry to the new Linux uid.
'newrole' re-authenticates the existing SELinux user identity (not the
current Linux uid, and there is no new Linux uid for newrole) to guard
against calls by malicious code; in this newrole case, the control over
entry is truly provided by the policy configuration.  'su' involves a
change only to the Linux uid, not the SELinux user identity.

--
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: revising the su decision

[Brad Chapman]

Mr. Coker,

--- Russell Coker <russell@coker.com.au> wrote:
> Up until now the su program was not modified, so changing to a different UID 
> was a separate and independant operation from changing domain via newrole.
> 
> However now that the sshd policy has been set to default to not allow logins 
> as sysadm_r:sysadm_t this causes some inconveniance.  I have to ssh in to my 
> server as a non-root account with a non-sysadm_r context.  Then I have to use

> newrole to change to sysadm_r (entering the password), and then I have to su 
> to the root account (entering the root password).
> 
> This requires entering the password two times (or three if not using ssh 
> authorized_keys).
> 
> This is excessively painful, and I think that to make SE Linux more usable we

> need to address this issue, possibly by changing su to allow it to change 
> roles too.
> 
> What do you think?

          Why do you have to change your role to sysadm_r before su'ing to
root? I was under the impression that becoming uid 0 by either logging in or
su'ing was sufficient.....

Brad


=====
Brad Chapman

Permanent e-mails: kakadu_croc@yahoo.com
		   jabiru_croc@yahoo.com
		   tanami_croc@devel.lbsd.net

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.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: revising the su decision

[Stephen Smalley]

On Fri, 12 Jul 2002, Brad Chapman wrote:

>           Why do you have to change your role to sysadm_r before su'ing to
> root? I was under the impression that becoming uid 0 by either logging in or
> su'ing was sufficient.....

The Linux root uid is not privileged with respect to the SELinux
mandatory access controls.  Hence, in order to perform most administrative
operations, you have to be both sysadm_r:sysadm_t and have the Linux root
uid (or at least the proper 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.

Re: revising the su decision

[Russell Coker]

On Fri, 12 Jul 2002 13:26, Stephen Smalley wrote:
> On Fri, 12 Jul 2002, Brad Chapman wrote:
> >           Why do you have to change your role to sysadm_r before su'ing
> > to root? I was under the impression that becoming uid 0 by either logging
> > in or su'ing was sufficient.....
>
> The Linux root uid is not privileged with respect to the SELinux
> mandatory access controls.  Hence, in order to perform most administrative
> operations, you have to be both sysadm_r:sysadm_t and have the Linux root
> uid (or at least the proper Linux capabilities).

I think that Brad was asking why I login to a non-root account first.

One issue is the lack of dotfile support you mentioned before, although I 
could probably address that by having a PAM module that sets a different home 
directory used by the ssh config.

Another issue is that of auditing.  Having a non-root identity makes many 
things easy to solve when a number of people have root and sysadm_r access.

-- 
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: revising the su decision

[Jesse Pollard]

Russell Coker <russell@coker.com.au>
> 
> Up until now the su program was not modified, so changing to a different UID 
> was a separate and independant operation from changing domain via newrole.
> 
> However now that the sshd policy has been set to default to not allow logins 
> as sysadm_r:sysadm_t this causes some inconveniance.  I have to ssh in to my 
> server as a non-root account with a non-sysadm_r context.  Then I have to use 
> newrole to change to sysadm_r (entering the password), and then I have to su 
> to the root account (entering the root password).
> 
> This requires entering the password two times (or three if not using ssh 
> authorized_keys).
> 
> This is excessively painful, and I think that to make SE Linux more usable we 
> need to address this issue, possibly by changing su to allow it to change 
> roles too.
> 
> What do you think?

I'm not sure that is a good thing - (depends on the security policy).

The separation now means that a root compromise is not all that usefull.

Consider what happes if a root compromise performs a "su - root". It
currently looks like the compromise would suddenly get whatever role has
been assiged to root.

The advantage of the newrole is to REQUIRE a password before gaining
sysadm_r.

Now, If you merge the newrole functions into su and remove the automatic
su to itself (ie su root when root still requires a password, AND su to
any account requires a password), then my objections are much weaker.

My experience are from non SELinux systems (UNICOS MLS, where this wasn't
allowed either). IF the user logged in a non-privileged account, then
that user couldn't GAIN privileges just by performing a su (even with the
password). In this situation (connections over an untrusted network), the
privileged user DIDN'T get even the privilege the account was authorized
(got the security level and compartment authorized on the network instead).
Whichever was minimum (network label or account minimum).

This eliminates the ability of an account compromise (from offsite) gaining
access to sensitive files, even if the account was authorized access.

As an aside - this level of security weakened considerably after SGI
took over UNICOS.

Another item - su is designed to set UID access (files and such), not
external privileges. Used with the root account which had UID access to
everything, you gained all priveleges. This change looks like a step toward
an all powerful account.

Yes it is convienent for some things - but it also makes the system more
vulnerable.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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: revising the su decision

[Natr Brazell]

Just joined this mailing list so perhaps my question is already answered  
however...

...  I work in an R&D environment with machines that are usually up and 
configured for the duration of the experiment and then scrapped and 
reloaded  for the next experiment.  Usually a time span of two months at 
the most.  While in the experiment there are several tasks that must be 
done consistently across all of my machines such as verifying time sync 
with ntp etc.  In the past we used rsh (no really) with .rhosts files and 
wrote scripts to push from a single entry point to manage all the machines 
at the same time.  We also use this configuration to push new software 
builds (every morning) across all machines.  When I say all machines I am 
addressing 30-65 or more PCs.  Using SELINUX is a requirement at the 
facility I am at even though no one knows anything about selinux expect 
how to spell it so I guess I am the expert.  (Haven't got the T-Shirt yet) 
but I have got people looking at my configuration as a starting point for 
future projects.  Now to my question...

...  What is this lists proposal for how to manage and push to multiple 
machines quickly and securely based on the above comments?

Nate Brazell
BMH Associates, Inc
Leaders in Modeling and Simulation
System Administrator
> Mr. Coker,
> 
> --- Russell Coker <russell@coker.com.au> wrote:
>> Up until now the su program was not modified, so changing to a
>> different UID  was a separate and independant operation from changing
>> domain via newrole.
>> 
>> However now that the sshd policy has been set to default to not allow
>> logins  as sysadm_r:sysadm_t this causes some inconveniance.  I have
>> to ssh in to my  server as a non-root account with a non-sysadm_r
>> context.  Then I have to use
> 
>> newrole to change to sysadm_r (entering the password), and then I have
>> to su  to the root account (entering the root password).
>> 
>> This requires entering the password two times (or three if not using
>> ssh  authorized_keys).
>> 
>> This is excessively painful, and I think that to make SE Linux more
>> usable we
> 
>> need to address this issue, possibly by changing su to allow it to
>> change  roles too.
>> 
>> What do you think?
> 
>           Why do you have to change your role to sysadm_r before su'ing
>           to
> root? I was under the impression that becoming uid 0 by either logging
> in or su'ing was sufficient.....
> 
> Brad
> 
> 
> =====
> Brad Chapman
> 
> Permanent e-mails: kakadu_croc@yahoo.com
> 		   jabiru_croc@yahoo.com
> 		   tanami_croc@devel.lbsd.net
> 
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.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.



--
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: revising the su decision

[Tom]

On Fri, Jul 12, 2002 at 01:10:19PM -0400, Natr Brazell wrote:
> facility I am at even though no one knows anything about selinux expect 
> how to spell it so I guess I am the expert.  (Haven't got the T-Shirt yet) 
> but I have got people looking at my configuration as a starting point for 
> future projects.  Now to my question...
> 
> ...  What is this lists proposal for how to manage and push to multiple 
> machines quickly and securely based on the above comments?

I'm probably about as much expert as you are (no T-shirt, either) so
don't trust me unless someone else says I got it right, but this is
what I think would be the right way to do it:

a) SELinux basic assumption is not to trust, especially not remote
parties. that's a Good Thing(tm).

b) so, what you need is a trusted process ON the machines. ideally,
with a policy crafted specifically for it. I'll call this process
instwa, the "install watcher". it could be as simple as a cronjob
called every 5 minutes that essentially does:

if ( any file in /var/install ) then ( rpm/dpkg/whatever -i $file )

c) give your remote/install user write priviledges for /var/install

d) voila. you can push software unto the machines and the instwa will
take care of the installation.

-- 
New GPG Key issued (old key expired):
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

--
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: revising the su decision

[Dale Amon]

On Fri, Jul 12, 2002 at 08:06:08PM +0200, Tom wrote:

> b) so, what you need is a trusted process ON the machines. ideally,
> with a policy crafted specifically for it. I'll call this process
> instwa, the "install watcher". it could be as simple as a cronjob
> called every 5 minutes that essentially does:
> 
> if ( any file in /var/install ) then ( rpm/dpkg/whatever -i $file )
> 
> c) give your remote/install user write priviledges for /var/install
> 
> d) voila. you can push software unto the machines and the instwa will
> take care of the installation.

Try cfengine2. That's what I use. (Not on selinux systems yet, but
I don't see why not)

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

--
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: revising the su decision

[Russell Coker]

On Fri, 12 Jul 2002 19:10, Natr Brazell wrote:
> Just joined this mailing list so perhaps my question is already answered
> however...
>
> ...  I work in an R&D environment with machines that are usually up and
> configured for the duration of the experiment and then scrapped and
> reloaded  for the next experiment.  Usually a time span of two months at
> the most.  While in the experiment there are several tasks that must be
> done consistently across all of my machines such as verifying time sync
> with ntp etc.  In the past we used rsh (no really) with .rhosts files and

It seems that your demands for security aren't as high as many of the people 
on this list, and your demands for usability are very high.  So I suggest 
just configuring the policy to allow sshd to transition to sysadm_r:sysadm_t 
and then make the default context of the root account be sysadm_r:sysadm_t, 
so you can ssh in as root to do whatever you need to do.

I'm sure that many people will disagree, and it's not how I'd setup a serious 
production server.  But for the type of environment you describe it should 
work fine.

-- 
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: revising the su decision

[Russell Coker]

On Fri, 12 Jul 2002 17:46, Jesse Pollard wrote:
> The separation now means that a root compromise is not all that usefull.
>
> Consider what happes if a root compromise performs a "su - root". It
> currently looks like the compromise would suddenly get whatever role has
> been assiged to root.

You are assuming here that root:user_r:user_t can su to any domain without a 
password, and that a default su to a domain will get the maximum SE Linux 
privs.

The former assumption is not what I had been thinking of, and the latter is a 
matter of policy.

I had imagined that the ability to do "su - account" without a password would 
depend on both UID=0 and being sysadm_r:sysadm_t.

> The advantage of the newrole is to REQUIRE a password before gaining
> sysadm_r.

Yes, but that doesn't stop us from having one program doing both
"newrole -r sysadm_r" and "su -" functionality.

> Now, If you merge the newrole functions into su and remove the automatic
> su to itself (ie su root when root still requires a password, AND su to
> any account requires a password), then my objections are much weaker.

How about su to any account without a password gets the same result as such a 
su operation now, the source UID must be 0 and the context doesn't change.

I think that your disagreement is due to imagining a different way of 
implementing it to that which I had imagined.


Russell Coker

--
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: revising the su decision

[Russell Coker]

On Fri, 12 Jul 2002 20:06, Tom wrote:
> b) so, what you need is a trusted process ON the machines. ideally,
> with a policy crafted specifically for it. I'll call this process
> instwa, the "install watcher". it could be as simple as a cronjob
> called every 5 minutes that essentially does:
>
> if ( any file in /var/install ) then ( rpm/dpkg/whatever -i $file )
>
> c) give your remote/install user write priviledges for /var/install

If someone can write to /var/install in that case, then why not just allow 
them to login directly with full admin privs?

Writing a RPM or DEB package to take over or destroy a system is easy 
enough...

-- 
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: revising the su decision

[Natr Brazell]

This is a great idea for managing packages on the workstation however your 
recommendation is a pull instead of a push.  I need something that allows 
a developer the ability to push a single file or whole new software 
distribution depending on the needs.  We work with developers on hand to 
isolate and resolve issues on the fly (R&D remember).  Changes have to be 
released en mass on the fly.

Thanks,
Your suggestion has definate value.  I will use it for managing system 
related packages.

Natr  


> On Fri, Jul 12, 2002 at 01:10:19PM -0400, Natr Brazell wrote:
>> facility I am at even though no one knows anything about selinux
>> expect  how to spell it so I guess I am the expert.  (Haven't got the
>> T-Shirt yet)  but I have got people looking at my configuration as a
>> starting point for  future projects.  Now to my question...
>> 
>> ...  What is this lists proposal for how to manage and push to
>> multiple  machines quickly and securely based on the above comments?
> 
> I'm probably about as much expert as you are (no T-shirt, either) so
> don't trust me unless someone else says I got it right, but this is
> what I think would be the right way to do it:
> 
> a) SELinux basic assumption is not to trust, especially not remote
> parties. that's a Good Thing(tm).
> 
> b) so, what you need is a trusted process ON the machines. ideally,
> with a policy crafted specifically for it. I'll call this process
> instwa, the "install watcher". it could be as simple as a cronjob
> called every 5 minutes that essentially does:
> 
> if ( any file in /var/install ) then ( rpm/dpkg/whatever -i $file )
> 
> c) give your remote/install user write priviledges for /var/install
> 
> d) voila. you can push software unto the machines and the instwa will
> take care of the installation.
> 
> -- 
> New GPG Key issued (old key expired):
> 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
> 
> --
> 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.



--
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: revising the su decision

[Jesse Pollard]

Russell Coker <russell@coker.com.au>:
> On Fri, 12 Jul 2002 17:46, Jesse Pollard wrote:
> > The separation now means that a root compromise is not all that usefull.
> >
> > Consider what happes if a root compromise performs a "su - root". It
> > currently looks like the compromise would suddenly get whatever role has
> > been assiged to root.
> 
> You are assuming here that root:user_r:user_t can su to any domain without a 
> password, and that a default su to a domain will get the maximum SE Linux 
> privs.
> 
> The former assumption is not what I had been thinking of, and the latter is a 
> matter of policy.

I was basing it on the current functionality of "su". Right now, any use of
su will succeed for root. If additional options (not just "-") are provided
to establish a different security context, and that context change requires
a password, then my objections are overcome. The advantage of a different
option to set security context is that some (like some user support activity)
want to be able to switch to the users environment (minus the security context).
This would be accomplished by "su - user". To complete the security context
too, another option (how about something like "su - -s user") would allow
switching to user environment context and security context; but requires
a password (not necessarily the users password but that's a different subject).

It would also allow a "su -s user" to only setup the security context of that
target user account (good for verifying that the user context is correct).

> I had imagined that the ability to do "su - account" without a password would 
> depend on both UID=0 and being sysadm_r:sysadm_t.
> 
> > The advantage of the newrole is to REQUIRE a password before gaining
> > sysadm_r.
> 
> Yes, but that doesn't stop us from having one program doing both
> "newrole -r sysadm_r" and "su -" functionality.

No it doesn't. Should work fine, with the additional safegards that are
implicit in the "newrole".
 
> > Now, If you merge the newrole functions into su and remove the automatic
> > su to itself (ie su root when root still requires a password, AND su to
> > any account requires a password), then my objections are much weaker.
> 
> How about su to any account without a password gets the same result as such a 
> su operation now, the source UID must be 0 and the context doesn't change.
> 
> I think that your disagreement is due to imagining a different way of 
> implementing it to that which I had imagined.

I was just imagining some of the various attacks using "su" to gain privileges
or context. I think that any security context change sould always require
a password, and hence, a real tty structure associated with the "su" process
for additional audit information (as to who/what is connected to that
tty/pty).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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