[redhat-lspp] Some where along the line it was pulled off the list.

[Casey Schaufler]

--- Klaus Weidner <klaus at atsec.com> 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
casey at schaufler-ca.com