I read previous discussions about it here. The argument IIRC is that making the default context staff_t adds a little bit of security.
IMHO, it adds no security whatsoever, since `ssh -l root hostname -t su -' gets you to sysadm_r without asking for a password. So how about changing the default policy such that ssh selects sysadm_r by default, which should minimize the inconvenience without really losing anything in terms of security?
On Sun, 2004-04-04 at 03:05, Alexandre Oliva wrote:
I read previous discussions about it here. The argument IIRC is that making the default context staff_t adds a little bit of security.
IMHO, it adds no security whatsoever, since `ssh -l root hostname -t su -' gets you to sysadm_r without asking for a password.
Do you have unlimitedUsers enabled in policy/tunable.te? That might explain it. Otherwise, the su should require re-authentication, as staff_t isn't normally authorized to skip authentication for pam_rootok.
On Apr 5, 2004, Stephen Smalley sds@epoch.ncsc.mil wrote:
On Sun, 2004-04-04 at 03:05, Alexandre Oliva wrote:
I read previous discussions about it here. The argument IIRC is that making the default context staff_t adds a little bit of security.
IMHO, it adds no security whatsoever, since `ssh -l root hostname -t su -' gets you to sysadm_r without asking for a password.
Do you have unlimitedUsers enabled in policy/tunable.te? That might explain it. Otherwise, the su should require re-authentication, as staff_t isn't normally authorized to skip authentication for pam_rootok.
Nope, I just happened to have setenforce 0, in which case su - doesn't require a password. I was hoping the message wouldn't make it through moderation, since I had this `doh!' moment right after posting it :-/
selinux@lists.fedoraproject.org
-
Alexandre Oliva -
Stephen Smalley