[cap-talk] More Heresey: ACLs not inherently bad

Karp, Alan H alan.karp at hp.com
Thu Sep 25 10:19:59 CDT 2008

Marcus Brinkmann wrote:

> > O The virus problem
> I know that the theory is that Unix is just as vulnerable to viruses
> as Windows, and that attackers are just picking the lowest hanging
> fruit.  However, although from an operating system design perspective
> Windows and Unix are not very different, the socio-economic factors
> are very different between Windows and GNU/Linux.  The virus problem
> may be attributable to other causes than the failure to apply POLA at
> a finer level than users.  I think we are lacking data for comparison.
A Linux version of the Love Letter virus would be as effective as it was on Windows.  Opening the attachment grants the programmer of the virus all the user's authority.  There is no fix because the system is running the way it was designed to run.  I believe the reason we haven't seen such attacks on Linux is the dearth of toolkits for generating them.
> There are other potential problems I see with your reasoning as well.
> Viruses may just as well spread from browser to browser than from user
> to user.  To be member of a botfarm it may be sufficient to have some
> CPU resources, a virtual machine to execute in, and internet access.
> For phishing user data, it's usually sufficient to ask for it.  It's
> not clear to me that avoiding per-user viruses is sufficient to
> address the problem.
These are different problems that require different solutions.  Capabilities don't prevent human engineering attacks, although not deluging users with "May I?" dialog boxes may help.

> > O The problems with managing ACLs are well known
> My main interest are desktop systems.  These systems must be
> preconfigured, and their configurations do not need to be very
> dynamic.
Which is why every process runs with far more authority than it needs for the task at hand, making users far more vulnerable to the variety of attacks that we see.  I tracked the Microsoft patches for 18 months.  Over 3/4 of the vulnerabilities they patched enabled the attacker to take control of the running process.  If that process had few privileges, the attack wouldn't have been worth doing.  However, you can't do that if you assume the configuration of permissions is nearly static.

> > O managing rights at fine granularity
> This presumes a need for managing access at that level, which I only
> see for a couple of applications.  I am not worried about solitair.exe.
It's an everyday problem.  I want to share with you access to a document we're working on together.  My only real option is to let you mount my drive, but that gives you access to far more than I would prefer.

> > O User-Group-World is too crude a sharing model.
> I am not sure which use cases require that fine manipulation of ACLs.
Alice shares with Bob.  Bob wants to share with Carol, but he can't without being allowed to change the ACL.  If it's not convenient for Alice to change the ACL for Bob, then Bob will give Carol his credentials.  By making sharing at a fine grain impractical, you lose security by forcing people to give out all their rights in order to do their jobs.
> > O Object capabilities make it easier to write applications in which
> > a single breach doesn't compromise the entire program.  Security
> > reviews of such programs are considerably simpler.
> >From my experience of working on the GNU/Hurd, debugging such
> applications is a lot harder, because it is harder to identify objects
> and the processes implementing them and following execution flow
> across process domains.
Limiting the permissions individual processes (or objects) have reduces the number of places that could have produced some error.  Take a look at the DARPA Browser report or the recent security review of the Waterken server.

More later.  I'm about to disappear into a 2-day meeting :(

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

More information about the cap-talk mailing list