linux-kernel - Re: AppArmor Security Goal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4738E6E3.5090404@crispincowan.com>
Date:	Mon, 12 Nov 2007 15:50:59 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	"Dr. David Alan Gilbert" <linux@...blig.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM ML <linux-security-module@...r.kernel.org>,
	apparmor-dev <apparmor-dev@...ge.novell.com>
Subject: Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote:
> * Crispin Cowan (crispin@...spincowan.com) wrote:
>   
>> I mostly don't see this as a serious limitation, because almost everyone
>> has their own workstation, and thus has root on that workstation. There
>> are 2 major exceptions:
>>
>>     * Schools, where the "workstations" are thin client X terminals and
>>       everyone is logged into a giant shared machine. Sorry, AppArmor is
>>       not a good choice for that environment, but it is a pretty scarce
>>       environment.
>>     * Enterprises, where workers get their own workstation, but they
>>       don't get root. Well, the reason the worker doesn't get root is
>>       the enterprise doesn't trust them with it, and so not letting them
>>       edit security policy is probably a good idea.
>>     
> I don't actually see your distinction here between those two environments;
> why does it matter if there is one non-priveliged user or many?
>   
Because it is easier to solve if there is only one non-privileged user:
you just give them privilege (fun with chmod and sudo) to edit the
system policies, and you're done (assuming you are happy allowing the
non-privileged user to edit policy at all).

If there are lots of non-privileged users sharing a computer, then I
submit that solutions are either insecure, intractable, or purely
restrictive.

>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>>     
> I think it might depend on how strict the users starting point is;
> you could say:
>    1 This document editor can read and write any part of the users home
>      directory other than the . files.
>
> or you could say:
>    2 This document editor can read any files but only write to the
>      'Documents directory'.
>
> If the adminisrator set something up with (2) as the starting point it
> would seem reasonable for the user to be able to add the ability to edit
> documents in extra directories for their style of organising documents
> they work on; but they would be restricted in what they could add
> so that they couldn't add the ability to write to their settings
> files.
>   
Ok, I can see where that would be useful in theory. But solving it is
VERY hard in practice, and AppArmor is not attempting to address this
problem of user extensibility of mandatory access controls.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/