>SELinux has an independent user identity model, which provides for more rigorous identity based access control than standard Unix. e.g. you can change Unix user id, but not SELinux user id.
And that's a feature is it?
>The reason there are separate databases is that there is not a direct
>mapping between Unix users and SELinux users.
That's not a justification, it's a consequence of the fact that you are maintaining a separate database. In other words, that's a bad thing, not a good thing.
>Many users in /etc/passwd can be mapped to a single SELinux user for access control purposes (e.g. system_u).
Sounds like /etc/group to me.
>There also needs to be a way to map the user to a set of roles, so a separate database is needed anyway.
Yes, a separate database is required here to extend the data stored in /etc/passwd. But it should be analogous to /etc/shadow (which also extends the data stored in /etc/passwd). The important difference is that the "primary key" in /etc/shadow refers to the "primary key" in /etc/passwd. Of course, without an RDBMS, referential integrity is not enforced, but violations are meaningless - an orphan record in /etc/shadow is simply ignored.
SELinux keeps two separate databases with no relationship between primary keys.
And by the way, Russell mentioned that we have to consider NIS, LDAP, and other storage mechanisms. Those storage mechanisms are storage mechanisms, not separate databases, meaning that if you maintain a user database in NIS and duplicate the information in an LDAP directory, you're simply storing the same data in two places.
The arrangement that SELinux uses is like keeping two different customer files and assigning two different customer ID numbers to the same customer - that's trouble.
-- Murphy
