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

From: Leonid Yegoshin <[email-masked]>
Date: Thu, 11 May 2000 15:38:34 -0700

>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).

	       - Leonid Yegoshin.

---

From: "James P. Salsman" <[email-masked]>
Date: Thu, 11 May 2000 15:54:10 -0700 (PDT)

Leonid,

>    information (like cookie but not limited).

Yes:

Browser operators may not want to send their files, recordings,
pictures, video, or other device inputs to arbitrary sites without
their explicit permission and direction. Therefore, browser
authors are encouraged to disallow the submission of forms
which include any kind of file upload by any means other than the
standard HTML operator-controlled buttons for form submission
without explicit instruction from the session operator to the
contrary. Accordingly, the size attribute, style sheets, and
document layers should be prevented from obscuring any kind
of file upload widget if they are capable of accepting a default
filename. Furthermore, just as the operator may take direct
action to initiate, terminate, review and edit recordings ... browser 
authors are encouraged to prevent HTML scripts from taking those and
similar actions, unless for example the operator has specifically
enabled such script actions with a security option. Even then,
such preferences may be specified by the operator to reset after
an interval or at the end of the browsing session. Finally, explicit
information should be provided by the browser to the operator to
insure that the operator is fully informed when files are being uploaded. 

Cheers,
James

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 12 May 2000 08:17:31 +0100

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",
"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...

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...
so the solution is to ditch indecent systems. 

In message <[email-masked]>, Leonid Yegoshin typed

 >>    information (like cookie but not limited).

 cheers

   jon

---

From: Markku Savela <[email-masked]>
Date: Fri, 12 May 2000 11:08:34 +0300 (EET DST)

> "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,

I think we should "turn around the view" (maybe you were saying this
in another way).

That is, instead of ACL type protection, where a resource is
associated with a list of allowed users and uses, we should have a
list of allowed resources and uses attaced to each program
(exectutable or active object).

And by default, a program could not access any resources at all.

In case of mail attachment containing an executable, we could quite
safely try to run it, and the system would just inform that it tries
to open this or that file (do you want to allow it?), trying to
open TCP connection to port 25 (do you want to allow it?), or tries to
execute another program (do you want to allow it?).

To make such thing work, program installation packages would need to
be accompanied with a "resource usage list", which could be checked by
the user, and if acceptable, and then associated with the program.

I don't see it causing much overhead. For example, linux program
loader could be changed to load the usage list, and on open file, it
is not a big issue in scanning this list whether the access is allowed
or not. Most programs really need access to few files and resources
anyway (and naturally, there would be ways to give access to wide
range of resources, if needed -- the old group/owner uids would be
still available for that purpose)

-- 
Markku Savela ([email-masked]), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/