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'?
* Why does the 'netlabel_mgmt_t' domain insist on performing a role
transition to 'system_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 ;)
--
paul moore
linux security @ hp
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
