[redhat-lspp] MLS email - worth doing?

[Russell Coker]

I've been thinking about the issue of labeled email.

Previous discussions in this regard has been based on the MTA tracking
the security context of the message through all operations which would
mean adding an extra meta-data field to all structures that deal with a
message (heaps of work and pain).  One of the ASF people who was working
on JAME (Java Apache Mail something) liked this idea but ended up not
doing any code (this was several years ago, I'm sure that he would have
released something by now if he was going to do so).

However it seems that a better option is to have the process that
receives the message (be it a binary named "sendmail" or a process
listening on port 25) put an extra header in the message describing it's
security context.  Those programs already have code to add extra headers
and storing an arbitrary set of headers is the standard operation of all
MTA components.

So we would want the process receiving the message to put a header in
(in the case of Postfix it's "smtpd" for network connections and
"postdrop" or "sendmail" for locally sourced email).  Then the delivery
process (in the case of Postfix it's named "local") would do the
appropriate delivery mechanism.  In the basic case it would involve
running procmail with the appropriate context.

There are three issues related to procmail and SE Linux support:

1)  Running it in the role $ROLE_r and domain $ROLE_procmail_t.  Easy to
do, put something like domain_auto_trans(mta_delivery_agent,
$1_home_dir_t, $1_procmail_t) in mta_macros.te and then do checks
equivalent to what crond does.

2)  Getting the correct level.  One way of doing this would be to have a
procmail config file for each supported level.  The MTA could run
procmail at the appropriate level and it could then (without knowing
much about MLS) try reading config files in order of level.  So for
example if procmail is run at "secret" level then it would try
unsuccessfully to read config files for "unclassified" and "classified"
before trying to read the file for "secret".  If there was no config
file for "secret" then it would look for a config file for "top secret".
If a user is not expecting to receive "secret" email then the mail would
automatically be upgraded to "top secret", if the user has no config
file for that (EG they only have "classified" clearance) then the mail
would bounce.

3)  Categories.  Supporting all combinations of categories is something
I don't know how to address.  If someone has Procmail configurations for
category combinations "c0,c2" and "c0,c3" then what do we do with a
message that is classified with category "c0"?  Obviously delivery
requires upgrading it, but which of the two equally appealing options
should be taken?  I guess we could have an ordered list of Procmail
config files and it could just try them in order and use the first one
it can read.

The next thing is bounces.  A large portion of bounces do not go to the
originating user.  Therefore it will be quite common for a bounce to be
directed to a user who has no clearance to receive it, and thus MLS
support in the MTA will significantly increase the incidence of
double-bounces.  Not sure what we might have to do in regard to this.


So is MLS labeled email regarded as desirable?  Apart from the issue of
categories it's not that difficult to do.  I'm speaking at a conference
in a couple of weeks so I won't be able to get the coding for this done
until at least the end of the month.  It's probably about a week's work
for a first-cut at doing all this in Postfix.