[cap-talk] Polaris: Virus Safe Computing for Windows XP

[Karp, Alan H]

Jed Donnelley wrote:
> 
> "E.g. I'm running two instances
> of Notepad?  Nominal Windows behavior is last
> write wins (just tested).  It would seem that under
> Polaris that behavior would change to last exit wins."
> 
The synchronizer updates the file as soon as it detects a change to the
copy.  Since the detection is not instantaneous, there's a chance of
updates occuring in the wrong order, but I don't think it's a problem in
practice.  Indeed, most applications won't open a file for write if it's
already open for write.  Polaris is supposed to mimic this behavior, but
I just tested it, and it doesn't work.  I'll have to file a bug report.
> 
> "By properly distinguishing authority from permission, 
> Polaris doesn't 
> leave any
> dangling permissions to be cleaned up later."
> 
> from the Polaris paper.  Perhaps it was just that wording that
> was bothering me, sounding like an overly broad claim.  Of course
> Polaris is granting what amounts to revokable (indirect)
> rights.  From the viewpoint of the Windows application
> running "RunAs", it has permission to access "the" file.
> 
Correct, but from the viewpoint of the ACL no such permission exists.
There's a real difference in this case.  If we modified the ACL to give
the pet read permission to the file, that permission would survive a
reboot until Polaris did some cleanup.  Using the synchronizer means
that the ability of the pet to modify the file does not survive a
reboot.  Whatever you call these two cases, that's a useful feature.  
> 
> In fact, now that I've focused on this point so much
> (sorry to others if I seem to be beating a dead horse),
> it occurs to me to wonder why this indirection is
> needed at all.  Doesn't the importance of that
> indirection for Polaris result exactly from the fact
> that it uses RunAs (CreateProcessWithLogon)
> as its restricted execution environment?
> 
Not specifically.  If I logged into a pet account and launced Excel
directly, there's be no RunAs involved.  As long as the PowerBox running
as a system service recognized this process as running in a pet, opening
a file would work the same as described in the paper.  (Well, at least
it should, but we don't have the PowerBox running as a service today.)
The critical point is that the process running the application only has
access to files outside its installation endowment via the PowerBox.
> 
> On the other hand with the sort of mechanism I
> described in:
> 
> http://www.eros-os.org/pipermail/cap-talk/2004-December/002603.html
> 
A much better solution, but one that is far beyond our abilities on
Windows.  We originally planned to do something along these lines on
Linux.  Given the resources, we might still.
 
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20041210/e89b691f/KarpAlanH.vcf