From: Jon Crowcroft <J(_dot_)Crowcroft(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
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
<200005112238(_dot_)PAA00950(_at_)leonid(_dot_)genesyslab(_dot_)com>, Leonid
Yegoshin typed
:
From: "James P. Salsman" <bovik(_at_)best(_dot_)com>
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).