Tracy Reed wrote:
On Thu, Feb 19, 2015 at 11:33:03PM PST, Dominick Grift spake thusly:
Right, this table (login table) shows the associations of selinux
identities
and selinux securtity levels with linux users, whereas the "user
table" shows
associations of selinux roles and security levels with selinux users.
Ok, I think I understand that now... Looks like they both can associate
security levels with their respective kinds of users. Seems odd now to
be able
to associate security levels with Linux users instead of just SELinux
users.
Now I am wondering which one takes precedence. For example, in the MCS
setup I
am attempting do I need to have the security category defined in the
login
table or the user table or both?
SELinux users have a strict superset of the levels that Linux users do.
The SELinux kernel policy does not know or care about Linux users. It
only knows SELinux users, they are defined in the policy and have a set
of levels associated with them. The tools below adjust those levels as
they are defined in the kernel binary policy.
Originally there was no Linux user->SELinux user mapping at all, that
was added so that Linux users didn't need to be added to the SELinux
binary policy, before these management tools existed.
Nowadays, in the managed policy case, you can associate a subset of the
levels of an SELinux user to a Linux user. This is enforced by the login
program and not by the kernel. The kernel will only enforce the SELinux
user does not gain more levels than assigned in the policy.
Does that make sense?
You are misunderstanding the concept of associating things with "selinux
users" (user table) versus the concept of associating things with "linux
users" (login table), and how the two relate.
Indeed.
You cannot associate something with a Linux user if that something is
not
associated with the SELinux user first.
Ok...
For example the error message above complains that you have a
"appuser_u"
identity associated with some "linux user(s)" (p16002, p16003).
Howver that
identity (appuser_u) does not exist in your "user table".
So to fix that error: re-add the appuser_u selinux user to the "user
table" ,
then remove the references to "appuser_u" from the "login table"
*first* ,
and then finally remove the appuser_u association from the "user table"
again.
Your use of "*first*" in the second step is confusing to me but it
looks like
the order of operations here is:
1. re-add the appuser_u selinux user to the "user table"
2. remove the references to "appuser_u" from the "login table"
3. remove the appuser_u association from the "user table"
So to do step 1 and re-add appuser_u selinux user to the "user table"
I should do this and get this result:
# semanage user -a -R user_r appuser_u
libsemanage.validate_handler: selinux user appuser_u does not exist
(No such file or directory).
libsemanage.validate_handler: seuser mapping [p16002 -> (appuser_u,
s0:c1.c499-s0:c2)] is invalid (No such file or directory).
libsemanage.dbase_llist_iterate: could not iterate over records (No
such file or directory).
/usr/sbin/semanage: Could not commit semanage transaction
Even if I try step 2 first (in case that's what you meant by *first) I
get this:
# semanage login -d p16002
libsemanage.validate_handler: selinux user appuser_u does not exist
(No such file or directory).
libsemanage.validate_handler: seuser mapping [p16003 -> (appuser_u,
s0:c1.c499-s0:c3)] is invalid (No such file or directory).
libsemanage.dbase_llist_iterate: could not iterate over records (No
such file or directory).
/usr/sbin/semanage: Could not commit semanage transaction
What am I missing here? Thanks!
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to
Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
