Russell Coker wrote: > That will work too. Lots of things will work, you just have to decide > which is most appropriate given your security goals. If anyone has > given much thought to implementing read-only files with MCS they don't > seem to have written about it publicly, so this is all new. Okay then I will implement this and see how it works. > One Unix UID can have multiple SE Linux contexts. The mapping of Unix > account name to UID doesn't have to be 1:1. But if you have multiple > Unix accounts with the same UID then tools start to break. Uh. They may not break that much but it will still give those people 2 accounts to use, be it usernames or selinux users; the UID is the least relevant here. In fact, the beauty of MCS is that I could map everyone to UID 0 and data access protection would still work as expected. Some apps tend to derive usernames for audit purposes from getuid(), though, so that would be a minor annoyance. > Another possibility to consider is to give some file types an > exclusion for read checks in the constraints. That would mean that > anyone could read them if the TE rules permit but MCS levels constrain > write access. Fair enough, but actually I need to provide three levels of access, "none", "read only" and "full". The low/high range trick works here, but I wonder if it would still be applicable if I wanted for example to add a "create and append only" in between. Michal Svoboda
Attachment:
pgprMGWzUM0Fq.pgp
Description: PGP signature
