RE: Hypothetical design question

[ljknews <ljknews () mac com>]

At 3:58 PM -0800 1/30/04, Shea, Brian A wrote:

> Having said that, here is my initial shot at some design highlights that I'd want to see to address this issue.

I seem to _have_ most of what you list below in my normal email client,
VMSmail (not used for mailing lists due to non-security issues).

> Secure OS as a base - The Operating System beneath the mail client MUST be secured to protect the system and sensitive 
> files from tampering to the degree it can.  Non-administrative contexts should be restricted from altering important 
> system files, registry data, etc.  Should be standard practice but worth mentioning.

VMS.

> Non-administrative user context - The context used to read mail, send mail, or deal with attachments initially should 
> be a non-privileged user context.  This should be enforced by the mail client if an admin logs on and tries to read 
> mail by "shedding" extra privileges at execution time from the Mail Client process token.  This might still be 
> vulnerable to RevertToSelf() attacks, but it is a reasonable first step IMO.

No execution context for email contents to require that.

> No HTML Mail - Inbound messages should have all "dangerous" tags removed if HTML formatting is allowed at all.  
> SCRIPT, IFRAME, OBJECT, EMBED, INCLUDE, and externally linked HREF should be stripped before the mail hits the 
> display, or better stripped at the server before the client has a chance to touch it.  Using HTML for formatting is 
> ok, but not using any form of scripting or code execution.  Links to external anything should not be allowed, if you 
> need a picture in the mail, embed it or forget it.

No HTML mail support.

> Sandbox the mail client, then further sandbox the attachment handling until a level of trust or assurance can be 
> reached - This might be overkill, I admit, but the attachment must be sandboxed, and I think that due to human errors 
> and smart attackers, the mail client should be too, to provide the extra assurance that there will be no issues until 
> some degree of trust can be established.

The only things possible with an attachment (SEND/FOREIGN) are to store it
in a folder or export it to a file.

> Integral AV scanning in mail client - No external software required to get AV Protection, it is provided by the mail 
> client itself, maybe as a plugin from AV vendors to avoid sig maintenance issues.

Antivirus scanners typically work by matching against patterns of known
viruses.  For VMS that is the null set.

> No "double-click to read" feature - do not allow the native programs to be called directly from the mail program, do 
> not allow viewing of the attachment right from the mail.  Attachments must be saved to fixed (but configurable?) 
> directory structure, and the AV "watches" this directory for new files and scans them as they come in.

EXPORT <newfilename> is the command and my virus comments above stand.

> Integrated key exchange protocols for establishing secure sessions and support for the "major" encryption standards 
> and hashing standards.

Nope.  VMSmail has none of that.  But since the MUA and MTA are on the
same machine, I don't see how "secure sessions" would be needed.  VMSmail
has no encryption or signature capabilities.