All of lore.kernel.org
 help / color / mirror / Atom feed
* su vs runuser
@ 2011-08-17 14:30 Ted Toth
  2011-08-17 15:09 ` Stephen Smalley
  0 siblings, 1 reply; 3+ messages in thread
From: Ted Toth @ 2011-08-17 14:30 UTC (permalink / raw)
  To: SELinux; +Cc: Daniel J Walsh

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

I've read that I should use runuser instead of su and I was having a problem
getting a script to transition properly until I changed it to use runuser
but I'm not clear on why this is. Can someone help me with an elevator
speech that I can use when trying to explain this to others?

Ted

[-- Attachment #2: Type: text/html, Size: 309 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: su vs runuser
  2011-08-17 14:30 su vs runuser Ted Toth
@ 2011-08-17 15:09 ` Stephen Smalley
  2011-08-18 10:40   ` Daniel J Walsh
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Smalley @ 2011-08-17 15:09 UTC (permalink / raw)
  To: Ted Toth; +Cc: SELinux, Daniel J Walsh

On Wed, 2011-08-17 at 09:30 -0500, Ted Toth wrote:
> I've read that I should use runuser instead of su and I was having a
> problem getting a script to transition properly until I changed it to
> use runuser but I'm not clear on why this is. Can someone help me with
> an elevator speech that I can use when trying to explain this to
> others?

runuser runs in the same uid (i.e. it is not setuid-root) and security
context as the caller - it isn't a trusted application.  It can only be
used if the caller is already privileged.  It never requires
authentication, and thus can be easily used in non-interactive scripts.

su is a setuid-root program that typically runs in a different security
context than the caller so that it can read user authentication secrets
(/etc/shadow) and switch identities even if the caller can't directly do
so.  Early versions of Fedora/RHEL also put pam_selinux
into /etc/pam.d/su, causing it to explicitly switch to the new user's
security context, but that was later removed.  But even without that,
there is a security context transition when you invoke su (to enter su's
domain so that you can read /etc/shadow and switch uid) and when su
invokes the user shell or command (to transition back to the original
caller's domain).

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: su vs runuser
  2011-08-17 15:09 ` Stephen Smalley
@ 2011-08-18 10:40   ` Daniel J Walsh
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel J Walsh @ 2011-08-18 10:40 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: Ted Toth, SELinux

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/17/2011 11:09 AM, Stephen Smalley wrote:
> On Wed, 2011-08-17 at 09:30 -0500, Ted Toth wrote:
>> I've read that I should use runuser instead of su and I was having
>> a problem getting a script to transition properly until I changed
>> it to use runuser but I'm not clear on why this is. Can someone
>> help me with an elevator speech that I can use when trying to
>> explain this to others?
> 
> runuser runs in the same uid (i.e. it is not setuid-root) and
> security context as the caller - it isn't a trusted application.  It
> can only be used if the caller is already privileged.  It never
> requires authentication, and thus can be easily used in
> non-interactive scripts.
> 
> su is a setuid-root program that typically runs in a different
> security context than the caller so that it can read user
> authentication secrets (/etc/shadow) and switch identities even if
> the caller can't directly do so.  Early versions of Fedora/RHEL also
> put pam_selinux into /etc/pam.d/su, causing it to explicitly switch
> to the new user's security context, but that was later removed.  But
> even without that, there is a security context transition when you
> invoke su (to enter su's domain so that you can read /etc/shadow and
> switch uid) and when su invokes the user shell or command (to
> transition back to the original caller's domain).
> 

The actual first line of runuser.c is

#include "su.c"

So basically they are the exact same program, except, runuser has its
own version of the pam stack functions that just return success.

Bottom line.  runuser is su without the pam_stack, it does not try to
run anything that is in /etc/pam.d/su.

Pretty much you have to run runuser as root and really should be used in
init scripts.

If you don't need to use any of the functionality in the pam stack, use
runuser, if you need to user "setuid" privs and want stuff in the pam
stack to run use su.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5M7AkACgkQrlYvE4MpobMVQACfUXL2RVMSMtltRtHnMqsoUgN6
8TIAn3WfJJy7b4IxPoFU2jFffbcB1+3u
=1g8T
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-08-18 10:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-17 14:30 su vs runuser Ted Toth
2011-08-17 15:09 ` Stephen Smalley
2011-08-18 10:40   ` Daniel J Walsh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.