Hi All,
I have employed SELinux on our Linux product for a few years now and
have written some simple custom policies on top of the base Fedora Core
7 'strict' policy.
I am using Standard Linux 2.6.14. And the SELinux related packages I am
using are:
checkpolicy 1.34.1
libselinux 1.34.7
libsemanage 1.10.3
libsepol 1.16.1
policycoreutils 1.34.6
I have the following user mappings and login mappings defined:
root@hapWibbSc2:/var# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ user_u s0
admin staff_u s0
root root s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
root@hapWibbSc2:/var# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range
SELinux Roles
root sysadm s0 s0-s0:c0.c1023
system_r sysadm_r staff_r
staff_u staff s0 s0-s0:c0.c1023
sysadm_r staff_r
sysadm_u sysadm s0 s0-s0:c0.c1023
sysadm_r
system_u user s0 s0-s0:c0.c1023
system_r
user_u user s0 s0
user_r
Question
========
Most of the time, when I SSH into the system as Linux User "admin", I
get a security context of "staff_u:staff_r:staff_t". Which is what I
actually want, given how I have configured policy and everything.
While the system runs over weeks at customer sites, (don't know exactly
what sequence of events transpire on the system, but possibly does
include several reboots), SOMETIMES, given the mappings described above,
when we SSH in as "admin", we get a security context of:
user_u:user_r:user_t ?!? This is obviously NOT desired, and causes my
strict policies to complain about things that should have ideally been
allowed as staff_t.
In these strange situations: I have tried restarting sshd. I have tried
rebooting the system. It doesn't seem to correct the problem !!
1. What could be causing this change all of a sudden ? How does this
happen given the semanage mappings above ??
2. What can I do to force the security_context for Linux user "admin" to
be reset back to "staff_u:staff_r:staff:t" manually ?
3.What can I do to make sure that the security context remains
staff_u:staff_r:staff_t always !
Any other useful pointers or things to check would be appreciated.
Thanks as always.
R.H.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
