On Wed, 2007-03-21 at 16:13 -0400, Paul Moore wrote:
> On Tuesday, March 20 2007 6:27:20 pm Loulwa Salem wrote:
> > Hi all,
> > I am seeing a strange behavior on my system. I am running with the latest
> > and greatest kernel (.69) and packages freshly installed today from Steve's
> > repo on a ppc system in Enforcing mode ofcourse.
> > Note: The ssh_sysadm_login and allow_netlabel booleans are both on.
> >
> > Steps to reproduce the problem:
> > - ssh into system with your admin user as sysadm role
> > ssh -l ealuser/sysadm_r/s0-s15:c0.c1023 localhost
> > - switch to root
> > /bin/su -
> > - execute any netlabel command
> > netlabelctl cipsov4 add pass doi:1 tags:1
> >
> > I am able to log in fine, and I expect the netlabel command to pass however
> > I get a permission denied. I am pasting at the bottom the relevant records
> > I see in the audit log (nothing shows up in /var/log/messages or secure)..
> > any ideas? Joy and Kylie tried this and both saw the same behavior. Keep in
> > mind this used to work just fine before.
> > What I find strange is the context it complains about has the role system_r
> > and not sysadm_r. Even in the records created by the ssh authentication, I
> > see the system_r, I'm not sure how that role is finding its way in there.
> > The "id" command however shows the correct sysadm_r.
> > I'm not quite sure what package is the suspect.
>
> I've spent the last couple of hours playing with this and looking at both the
> upstream refpolicy and the selinux-policy-2.4.6-45.el5 sources. Here is what
> I have found:
>
> * When you login at the console as root and get the default domain of
> 'root:sysadm_r:sysadm_t:SystemLow-SystemHigh' you are able to run the
> netlabelctl but the output going to the terminal seems to be denied
> (check the audit logs and you will see the changes taking place).
>
> * When you login via ssh to the same system over localhost ('ssh -l
> joebob/sysadm_r/s0-s15:c0.c1023 localhost') and get a domain of
> 'staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh' you see the problem
> that Loulwa described. Stephen posted that this is most likely due to
> netlabelctl performing a role transition to 'system_r' and the SELinux
> user 'staff_u' not allowed the 'system_r' role. This is most likely
> the case (see Karl's fourth law on the inherent correctness of Stephen)
> as the only real difference between the two SELinux users is the addition
> of 'system_r' to the 'root' user.
>
> This leads me to two questions:
>
> * Why does the 'netlabel_mgmt_t' domain not have write access to the
> 'sysadm_tty_device_t' object when the terminal context should be
> included in the 'admin_terminal' type attribute which is used in the
> call to 'netlabel_run_mgmt()' via 'userdom_security_administrator()'
> for 'sysadm_r'?
MLS-related denial?
> * Why does the 'netlabel_mgmt_t' domain insist on performing a role
> transition to 'system_r'?
As I understand it, because you declared it as init_daemon_domain(), and
daemon domains get role transitions defined to system_r so that if an
admin or rpm scriptlet starts or restarts a daemon, it moves into the
system_r role rather than staying in sysadm_r.
> As well as one realization:
>
> * The 'init_daemon_domain()' call in netlabel.te should probably be
> changed to 'init_system_domain()' but at this point I doubt that would
> solve the problem.
>
> I'm going to keep working on this, but if anyone has any ideas or answers to
> the two questions about I'd love to hear it as I'm no policy expert ;)
>
--
Stephen Smalley
National Security Agency
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
