On Mon, 2006-05-01 at 18:04 -0500, Klaus Weidner wrote:
> On Fri, Apr 28, 2006 at 07:31:33AM -0400, Stephen Smalley wrote:
> > On Thu, 2006-04-27 at 13:20 -0500, Klaus Weidner wrote:
> > > Currently, both users would need to be a "staff" user and need to know
> > > the shared root password. Once they are root, they can newrole to any of
> > > the administrative roles. There needs to be a place where the permitted
> > > roles for the original (pre-su) user are stored and checked. (This is
> > > assuming that people don't log in as root directly.)
> >
> > I'm not sure I follow. su no longer changes the context at all, so
> > su'ing doesn't alter the set of roles accessible to you - you are still
> > bound by the set of roles authorized for your SELinux user identity,
> > which didn't change upon su.
>
> Probably I'm misunderstanding something here. I'm using the following
> configuration:
>
> - create user "kw"
>
> useradd -m -G wheel kw
> semanage login -a -s staff_u -r SystemLow-SystemHigh kw
>
> with the following /etc/selinux/mls/seusers entry:
> kw:staff_u:s0-s15:c0.c255
>
> - log in as "kw", run "/bin/su -", which gets me the following
> context: staff_u:staff_r:staff_t:SystemLow-SystemHigh
> (note no "sysadm_r" or "secadm_r")
>
> Now I can use "newrole -r" to switch to sysadm and secadm with no
> further restriction.
That implies that staff_u is authorized in your kernel policy for those
roles. Otherwise, the newrole would fail. You are supposed to define
separate SELinux user identities for each desired role set, then map the
Linux users to the appropriate SELinux users via seusers.
> Is the intended procedure to not use "staff_u" and instead create new
> selinux user classes (such as sysadm_staff_u)? I tried using "semanage
> login -m -s sysadm_u kw" but that didn't permit me to login:
>
> type=AVC msg=audit(1145647282.899:809): avc: denied {
> transition } for pid=4510 comm="sshd" name="bash" dev=dm-0
> ino=229410 scontext=system_u:system_r:sshd_t:s0-s15:c0.c255
> tcontext=sysadm_u:sysadm_r:sysadm_t:s0 tclass=process
>
> Could you provide an example of how a sysadm-only user should be
> configured in the current system?
Don't allow staff_u both roles in the kernel policy.
--
Stephen Smalley
National Security Agency
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
