Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Jon Crowcroft
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

Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Markku Savela
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

RE: mail sandbox wall authority, inward and outbound

2000-05-12 Thread James P. Salsman
From: Jim Busse [EMAIL PROTECTED] 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

RE: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Jim Busse
- From: James P. Salsman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 12, 2000 11:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: mail sandbox wall authority, inward and outbound From: Jim Busse [EMAIL PROTECTED] Date: Fri, 12 May 2000 10:11:36 -0700 I get 240 emails/day

Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Leonid Yegoshin
From: Jon Crowcroft [EMAIL PROTECTED] 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

Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Leonid Yegoshin
From: Markku Savela [EMAIL PROTECTED] 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

Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread Markku Savela
From: Leonid Yegoshin [EMAIL PROTECTED] From: Markku Savela [EMAIL PROTECTED] 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

Re: mail sandbox wall authority, inward and outbound

2000-05-12 Thread James P. Salsman
Harald, Thank you for your reply to my message: These sorts of things are less common on the more heterogeneous Unix world, but Unix mailers are just as culpable. If I wanted to be consistent, I would demand that anything I run on Unix (without a special permitted shell) which connects to

Re: mail sandbox wall authority, inward and outbound

2000-05-11 Thread Leonid Yegoshin
From: "James P. Salsman" [EMAIL PROTECTED] 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

Re: mail sandbox wall authority, inward and outbound

2000-05-11 Thread Harald Tveit Alvestrand
At 13:10 11.05.2000 -0700, James P. Salsman wrote: These sorts of things are less common on the more heterogeneous Unix world, but Unix mailers are just as culpable. If I wanted to be consistent, I would demand that anything I run on Unix (without a special permitted shell) which connects to