--- Klaus Weidner <[EMAIL PROTECTED]> wrote:
> Multiple /var/spool/cron/ directories would be a > very invasive change - Yes, it is. And it's very messy to administer. I did it this way twice, and it is cumbersome. > if going that route, it would probably be easier to > use special filenames > (such as "/var/spool/cron/jdoe:s1") to indicate the > MLS level (or > optionally also user class, type and role). Cron > should then verify that > the actual MLS level of the file matches the > filename, and execute the > job in an appropriate context. This way has been done and is somewhat easier to deal with than using polyinstatiated directories. A hint. Put the attributes in the path name or on the file as an attribute, but don't do both. If you use an attribute make it an extattr that is explicitly for this purpose and not the attribute that gets used to control access to the file. You have already crossed over into the realm of application objects, and it's better that the attributes the enforceing application uses are explicitly for the policy that the appication is enforcing. > If the trusted programs involved are careful with > the MLS overrides, > there would be no risk of information leaks (only > things not working). > For example, a SystemHigh user can see the > SystemLow-created crontab file > and could load it into an editor, but would not be > permitted to write to > it. Conversely, the MLS constraints should prevent a > low user from > reading a high crontab. What I have found works best: Each user gets 1 (one) crontab file at the MLS value (You may want to extend this to the TE attributes as well. That's up to you.) of their home directory. This ought to be the user's "default" MLS value, which in turn ought to be dominated by all the labels in the user's MLS clearance range. Users are educated in the correct use of the program that allows them to run a program at a different MLS value (on various systems "su -M", "su -Z", "newlabel", etc) and instructed to use that in crontab entries. AT, batch, and cron refuse to work except at the user's default MLS value. > Aside from the integrity concerns (which are beyond > the scope of > MLS/LSPP), the implementation using a special > variable would sound > acceptable for LSPP compliance, assuming of course > that it's implemented > correctly. So long as you strongly associate the security attributes of the "job" with the "job", protect the "job" and its attributes from tampering, and reliably invoke the "job" with those attributes, you're fine. Resist the temptation to protect the user from MLS (or SELinux). This is a case where the user has choices, and your best bet is to provide the tools and education so that the user can make those choices correctly. Application objects. Erk. Casey Schaufler [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
