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

Karp, Alan H alan.karp at hp.com
Fri Dec 10 12:52:32 EST 2004

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

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

More information about the cap-talk mailing list