[redhat-lspp] multi-context aware cron

[Janak Desai]

Hello,

I have been looking at making cron multi-context aware.
I have some thoughts regarding possible approaches
and would appreciate your comments on them.

Cron background:
---------------
Cron as it exists now on SELinux, creates an entry,
per user, in /var/spool/cron. That is, if a user joe
uses the crontab command to setup a cron job,
/var/spool/cron/joe is created which stores the
details about the cron job. The cron daemon traverses
the /var/spool/cron directory and processes cron
jobs setup by different users. Before performing
a job on behalf of a user, the cron daemon assumes the
default (login) security context of the user. We need
to make cron daemon multi-context aware because it is
conceivable that a user or most likely an admin may
want to setup cron jobs after changing roles/levels.
In addition to individual user cron files, /etc/crontab
facilitates execution of admin scripts on an hourly,
daily, weekly and monthly basis by placing scripts in
/etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly
and /etc/cron.monthly directories respectively.
crontab is the command line interface for users to
create/list/edit their cron jobs, where as admins
can manually create/edit cron jobs in cron.hourly,
cron.daily, cron.weekly and cron.monthly directories.

Few weeks ago Chad posted the work done by TCS in this
area. TCS patch only makes cron multi-level aware and
depends on a polyinstantiation mechanism that is not
going upstream.


TCS patch:
----------
/var/spool/cron is polyinstantiated based on the process
sensitivity label. That is, /var/spool/cron will contain
"hidden" subdirectories that have different sensitivity
labels. If user joe is cleared to "Top Secret" he can
setup cron jobs for different sensitivity labels by
executing crontab while logged in using different
sensitivity labels. Because /var/spool/cron is
polyinstantiated, cron job files are created in the
respective hidden subdirectory of /var/spool/cron which
has the same sensitivity label as that of the process
that executed crontab. For example, the following shows two
different cron jobs (one at "Top Secret" and one at
"Unclassified") setup by user joe.

                         /var/spool
                             |
                           cron
                             |
           -----------------------------------------
           |          |         |          |
         (hidden  (hidden    (hidden      ....
         Top Sec)   Sec)    unclassified)
           |                    |
          joe                  joe

The cron daemon, avoiding polyinstantiation, looks at
/var/spool/cron directory. For each hidden directory, it
sets the process sensitivity label to match that of the
hidden directory, changes current working directory to
it and processes each of the cron job in it.

multi-context cron
------------------
In order to allow multi-context cron jobs, the job
file somehow has to convey to the cron daemon the context
of the process that created it. The cron daemon can then
duplicate appropriate process context when processing
a particular cron job.

The following lists some general approaches that I
could come up with. Please comment on them, improve
them or suggest a brand new one. Once we nail down
an approach I will flesh out details and create a
patch.

1) This is the most logical extension of the way cron
    works. Since the identity of the user is captured
    in the filename (i.e. /var/spool/cron/joe)
    we can extend the filename to capture the full
    security context. crontab will use getprevcon(3)
    to get the security context, append it to
    the username and create a file in /var/spool/cron.
    For example,
      /var/spool/cron/joe:system_u:system_r:unconfined_t:s0-s9:c0.c127
      /var/spool/cron/joe:user_u:staff_r:unconfined_t:s0-s9:c0.c127

    The cron daemon can then try and set the process context
    before processing the job. The downside of this approach
    is that we would have to make intrusive modifications to
    both crontab (for creating and filtering based on new
    naming convention) and cron daemon.


2) Polyinstantiate /var/spool/cron and extend TCS
    patch to cover full security context and not just
    sensitivity label. Generally follow the TCS logic but
    update in the following two areas.
      a) Migrate from TCS polyinstantiation mechanism to
         namespace based polyinstantiation. That is, update
         how /var/spool/cron is accessed while bypassing
         polyinstantiation.
      b) Instead of obtaining just the sensitivity label
         from the polyinstantiated subdirectory, obtain
         the full security context from its name. This
         will require changes to how current namespace
         based polyinstantiation works. In addition to
         allowing polyinstantiation based on user name
         and policy (from type member rules), we will have
         to allow polyinstantiation based on process
         security context alone. Also, a flag will have
         to be added to suppress MD5 hashes for
         polyinstantiated subdirectory names. These
         changes to existing namespace based polyinstantiation
         are not very difficult.


3) This is a bit of a hack, but I was trying to see if
    it is possible at all to not modify cron and crontab.
    It relies on changes to namespace based polyinstantiation
    mentioned in 2b)

    - Polyinstantiate /var/spool/cron, /etc/cron.{hourly,
      daily, weekly, monthly}, and /var/run based on
      process context.

    - Move default /usr/sbin/crond to /usr/sbin/crond_single_con.
      Provide a /usr/sbin/crond which is multi-context aware
      daemon. This daemon can bypass polyinstantiation and
      look at /var/spool/cron. For each of the polyinstantiated
      directories, it can fork a process, use setexeccon based
      on the context provided in the polyinstantiated directory
      name, and exec the original unmodified cron daemon
      (/usr/sbin/crond_single_con). Force single context crond
      to polyinstantiate using PAM. The daemon will only see
      cron jobs that were created by a process matching its
      context.


Notes/Questions:
----------------
None of the above approaches will handle the following
situation.  A user goes from role A -> B -> C and
creates a cron job. If the role C is not directly
accessible from default role A, cron daemon will not
be able to set the appropriate context. Do we have to
handle such cases, or can we just document this
restriction in the manpage?

Thoughts???

-Janak