[cap-talk] More Heresey: ACLs not inherently bad
Karp, Alan H
alan.karp at hp.com
Thu Oct 2 16:39:08 CDT 2008
Marcus Brinkmann wrote:
>
> Doesn't the majority of people use webmailers? Running executable
> attachments is not different from running executables from the
> browser---we almost lose nothing by making it difficult or even
> impossible. There just is no need. In a free software environment,
> executables come from your distributor, not over email.
So your answer is feature starvation. What else shouldn't I do? Open documents from unknown people? Enable macros in my spreadsheets? Where does it end? Isn't it better to limit the rights the running program has in order to limit the damage that gets done?
>
> No system I know provides resistance against "click here to see
> pictures of cute animals" attacks. This is also true for capability
> systems.
>
Polaris (not a capability system) is one that does, and I bet Plash does, too. I run my picture viewer under Polaris. If that click results in an attacker taking over the process running the viewer, the attacker only gets the privileges of a restricted user.
>
> However, attackers have the privilege of choosing whatever attack
> venue they want. Hardening solitair.exe gives you nothing. I am not
> familiar with Windows vulnerabilities, though, so I can't comment on
> your analysis. Were these local or remote attacks?
>
But I'm not hardening solitaire. I'm just running programs with least authority. The attack succeeds, and the attacker gets full control of the process, but that process only has the privileges of a restricted user. It doesn't matter where the attack comes from.
>
> Is this really an option? The only reasonable option I see today to
> share a file is by sending it over email. I probably wouldn't even
> get through your firewall (at least not legally :). Even when sharing
> documents via capabilities on a local computer is safe most
> collaboration will not occur within a single organizational unit (node
> or cluster for distributed capabilities). Do you think things would
> change?
>
Sending email attachments isn't the same as sharing access to files. Here in HP, we often mount drives to access files. Sharing files with capabilities across the web works just fine, as evidenced by the web site (forgot the name) that uses a form of webkey.
>
> Alice, Bob and Carol can just share copies of the documents they are
> working on. If there is a bigger project, they can create a group
> using some collaborative platform, such as version control systems or
> a CMS. This may require the involvement of an administrator, but as
> there are usually more requirements anyway, this doesn't do much harm.
> For example, the administrator may also take care of software updates,
> backups, etc.
>
Sharing copies is not the same as sharing access to a single file. You can't lock copies, for example. As far as the administrator is concerned, I use this example. Alice has some files in a SharePoint area. She asks the administrator to give Bob access, which requires Bob to have an account/password there. Bob now wants to share one of those files with Carol, but the administrator is out getting a root canal. What do you think Bob will do? He'll give Carol his password, and now Carol has access to all the files, not just the one Bob wanted to share.
>
> Of course, I am speculating here, as we don't have systems we can
> compare directly. But it is not true that people today need to give
> away all their authority to get the job done. I can give you an
> account to my wiki without giving you an account on the ftp server or
> my email, etc.
>
I agree. Managers don't give their assistants access to their bank accounts. However, they are forced to give out large chunks of authority when all they want to give is a small amount.
>
> I agree that this is also true. I just disagree with a simplified
> view that one system is strictly easier than the other to work with.
> This is not my experience. Some things are easier in the one type of
> system, some in the other. Of course, some of this is just a matter
> of having the right tools: gdb can follow execution flow in the case
> of fork+exec but not in the case of capability invocation. That is a
> feature that can be added, but it is more complicated nevertheless.
An operation that is complicated in one system may be simpler in another, so it's the overall balance you have to consider. The danger is in mistaking familiarity for simplicity. The complexity that's often ignored in ACL systems is the work needed to modify the ACL. It is so onerous that users of those systems simply don't do some things they'd like to do, such as sharing small sets of rights.
>
> The benefit in security review is probably due to encapsulation and
> explicit interfaces. Comparable benefits can also be achieved by
> other means, such as language design or coding conventions. Explicit
> interfaces can straighten one out considerably, but they can also
> dampy productivity if the need for them arises too early in the design
> process. To me, it's a wash, and I usually choose strategies
> according to requirements.
Capability discipline was a key factor in simplifying the review. If there had been even one instance of static mutable state, the reviewers would have had to look at every line of code to verify that there were no leaks of authority.
>
> I should also mention that different protection domains is
> unfortunately not identical to different failure domains. I had to
> learn that the hard way, and it took me a long time to understand the
> difference. Unfornutaley, it is much harder to create a new failure
> domain than to create a new protection domain.
Gee. I made that mistake, too.
>
> > More later. I'm about to disappear into a 2-day meeting :(
>
> Sounds awful. Good luck!
>
It was.
________________________
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
http://www.hpl.hp.com/personal/Alan_Karp
More information about the cap-talk
mailing list