MLS for Thunderbird or “O gosh, perhaps I shouldn’t have sent confidential info to a public mailing-list”
November 1, 2007 § 4 Comments
This entry is a brief presentation of an on-going work in progress by a group of my students in ENSI de Bourges, Vincent Tarbouriech and Roland Thaisong.
If your daily work is to deal with sensitive subjects, whether in a laboratory, in the industry, in an administration or in a newspaper, chances are that your computer will host a number of confidential informations. By definition, if someone who doesn’t have the necessary credentials gets their hands on this information, you’re in trouble.
As long as the information remains on your computer and your computer uses a reasonably safe operating system and you’re behind a reasonably safe firewall and you don’t need to communicate any information to anyone, you should be reasonably safe from malicious third-parties. However, if e-mail happens to be one of your work tools and if you may need some of that information to some people but not to others, accidental leaks become a definite possibility.
MLS stands for “Multilevel Security”, a security model by which
- every user has a clearance level ;
- a user may send information to any user of the same or higher clearance level ;
- a user may receive information from any user with the same or lower clearance level ;
- a user may decide to declassify information to a lower level, so as to be able to send that information to any user with a clearance level higher or equal to that declassified level.
This security model is built into a few operating systems such as Linux (when using SELinux) or Solaris (when using Solaris Trusted Extensions) and may be implemented in a few other systems using security modules, such as BSD. However, at the moment, the security model cannot apply to distributed systems, as security information is lost when transferring data on the network. In particular, while your clearance level may be high, once you send an e-mail to some low-level recipient, this e-mail stops belonging to you, rather belonging first to the anonymous mail agents then to the recipient. From the point of view of MLS, that’s a leak.
MLS for Thunderbird
The first objective of this project is to take advantage of SELinux’ built-in MLS layer and to add safe-guards inside the Thunderbird mail client to ensure that no leaks will happen. In other words, whenever a user sends an e-mail to email@example.com
- determine the clearance level of the sender, by interaction with the MLS layer
- determine the clearance level of the recipient, by interaction with the MLS layer, if that information is available, or a simple configuration file containing the clearances for the rest of the world
- determine the clearance level of all attachments, by interaction with the MLS layer
- if the clearance level of the recipient is too low to be allowed to receive information from the sender / from the attachments, pop-up a dialog offering to either not send the message or to declassify its contents.
Declassified e-mails will receive an additional header X-MLS-Declassified-Level, which may later be used for additional server-side security.
This will take the form of an extension for Thunderbird.
MLS for SMTP
The second objective of this project is to add a similar control for MLS on secure SMTP servers. In other words, whenever the SMTP server is asked to transmits an e-mail from firstname.lastname@example.org to email@example.com,
- determine the clearance level of the sender, either by interaction with the MLS layer, if that information is available, or a simple configuration file containing the clearances for the rest of the world
- determine the clearance level of the receiver, by similar methods
- check if the e-mail contains an additional header X-MLS-Declassified-Level
- if the clearance level of the recipient is lower than the declassified level (if available) and the original clearance level, reject the message with an error.
The exact form of this module is not decided yet.
- By the end of November, realize a UI prototype as an extension for Thunderbird.
- By the end of November, realize a XPCom component able to determine the SELinux clearance level of a file or user.
- By the end of December, have a working extension able to determine if a mail is licit based on SELinux clearance level of the sender and receiver, to pop-up a warning offering to cancel sending if the mail is not licit, and to add a custom header to the sent e-mail if sending has not been cancelled.
- By mid-January, complete the UI and add support for the configuration file.
- By the end of January, clean-up and submit to addons.mozilla.org .
- Work on server-side security starts in February.
- Ensuring that all this works even in the absence of SELinux.
- Adding the possibility to infer security from the contents of attached documents.
- Integrating all this inside milimail.
- Determine interactions with Majordomo and other mailing-list servers.