Subject: RE: mail sandbox wall authority, inward and outbound

From: "James P. Salsman" <[email-masked]>
Date: Fri, 12 May 2000 11:08:07 -0700 (PDT)

> From: Jim Busse <[email-masked]>
> Date: Fri, 12 May 2000 10:11:36 -0700
> 
> I get 240 emails/day.
> 
> about 15% have executable attachments, because that's the way developers use
> mail, we attach self-expanding zip files.
>
> My organization has about 100 people that fall into this category.

First off, not only would you all save space if you stopped 
exchanging self-extracting (executable) archives, but your 
organization would be far less vulnerable.  Use the ordinary 
zip files instead.
 
> I find it unacceptable that you are asking some console operator to
> 1.  Determine if my zip files are legitimate....

By "console operator", I mean you, the user, or whoever is 
sitting at your keyboard when your mail is being read.

Cheers,
James

---

From: Leonid Yegoshin <[email-masked]>
Date: Fri, 12 May 2000 12:10:12 -0700

>From: Jon Crowcroft <[email-masked]>
>
>the problem with sandboxes is that they are monolithic as is this
>discussion of mail - if i have a notion of a compartmentalized system
>with users, and access rights (like almost all operating systems from the
>late 60s onwards, but not like
>simple desk top single user executives as found on many personal
>computers today unfortuantely),
>then i can have mail agents run scripts, but with the authorities of
>the user, perhaps restricted further by some context, and i can then
>configure arbitrary rights w.r.t each possible tool that the script
>might invoke - some of these can be gathered togethre under the
>headings of "file input, output, exectution, creation etc", and others
>under the rights of "audio/video/mouse/itneraction with user",

  You right ... if we don't take into account the purpose of E-mail
exchange/web browsing. E-mails/web communication services a presentation
purpose. In strict point it is nothing to story/change in my permanent
files beyond E-mail archivation itself. Of course, it may _use_ public
resources on my host but not change it. If E-mail/HTTP hit wants to
store something it may have separate box archived with E-mail.
Three questions:

   - send files or something to outside (another user): it should be
     controlled by user approval for this particular mail/web site.
     This approval may be saved for future.

   - change/upgrade files on system (mail/HTTP upgrade):
     it should be approved by signature first and user approval second.
     Cookie/auth data may be considered as E-mail/HTTP private and
     it may be contained in sand-box itself.

   - Data extraction from E-mail/web page: it is difficult problem
     for security purpose because user may copy virus incapsulated
     in data object. It highly depends from object design. But at least
     it is not automatic and user should be seduced to do so.
     Love viruses are not final example of nature or dark invention.
     However it is possible to separate objects on script/execs
     and simple screen/voice presentation and warn user about difference
     during copy/extraction. Screen and sound speakers are also some kind of
     sand-box :-) (We may do not consider tools for pirat recording of
     played music or latest movie)

>"network i/o to such and such an address (list)", etc
>for conveneicnce and expressiveness in the ACL system (other
>management tools like user, other, groups etc help scale the task)
>and then i can design a set of sensible securioty policies for a site,
>and employ an expert to configure things for everyone - typically,
>with good systems, defaults and default operating system notions of
>user, file permissions, sudo type access etc, will suffice...
>
   Centralized rights configuration can't solve a problem.
The protection problem can be formulated in simple terms which are
clear and understandable for user. And end user decides about risk.
Nobody knows better about user trustees than user himself.
But to do so it is need to draw security boundary in convenient way for
end user.

>iff you start with a decent system;
>otherwise, forget it - someone will always find a way to set things up
>disastrously wrong, because it will be the only way to get work done
>....this is a standad problem with systems that impose all or nothing
>security - either they leak like a sive or users find them
>unusable...

  It depends on design. If high security is not huge unconvenience for
user then virus replication performance decrease dramatic and we lower
the number of people who wants to write them.

	       - Leonid Yegoshin.

>so the solution is to ditch indecent systems.
>
>In message <[email-masked]>, Leonid Yegoshin typed
>:
>
> >>>From: "James P. Salsman" <[email-masked]>
> >>>
> >>>A MUA might ask the console operator for permission to proceed when:
> >>>
> >>>1. A mail message wants to run a program.  (e.g., ECMAscripts.)
> >>>
> >>>2. An attachment is executable. (Nearly universal practice.)
> >>>
> >>>3. A program wants to write to a file.  (Usually not trapped more
> >>>than once per execution if at all.)
> >>>
> >>>4. A program wants to read your address book.  (Does any mail system
> >>>that offers this functionality limit it at all?)
> >>>
> >>>5. A program wants to send mail.  (e.g., having MAPI's Send notify
> >>>the user and queue the proposed message as a draft instead of sending.)
> >>>
> >> 6. A program wants to send a file to somewhere. Or any permanently stored
> >>    information (like cookie but not limited).