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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 10 Nov 2007 19:59:45 -0800
From:	John Johansen <jjohansen@...e.de>
To:	david@...g.hm
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Dr. David Alan Gilbert" <linux@...blig.org>,
	Crispin Cowan <crispin@...spincowan.com>,
	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

On Sat, Nov 10, 2007 at 05:27:51PM -0800, david@...g.hm wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear example is wanting to wrap a specific tool with temporary
>> rules. Those rules would depend on the exact file being edited at this
>> moment - something root cannot know in advance
>> (although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
>> mv it back might work 8))
>
> the mechanism being desired was that the system administrator would setup a 
> restrictive policy and a user who wanted a more permissive policy would 
> have the ability to make it more permissive.
>
> this sort of thing is a disaster waiting to happen.
>
yep

> however, if App Armor sets things up so that there can be a system policy 
> that users cannot touch, but users can have a secondary policy that layers 
> over the system one to restrict things further it could be safe.
>
> if a sysadmin wants to have 'soft' and 'hard' limits of what a user can do, 
> they could put the 'hard' limits in the system policy (and the users 
> _cannot_ violate these limits), and then set the 'soft' limits in the users 
> default setup (similar to how .profile is set by default). if a user wants 
> to make things less restrictive they could edit or remove the per-user 
> policy, but would still not be able to violate the system policy.
>
> however, while this seems attractive, I'm not sure that madness isn't down 
> the road a little bit. since the users policy would only apply to 
> themselves, you have the situation that (DAC permissions permitting) the 
> files are available to other confined processes becouse they are running as 
> other users. this sort of thing will surprise people if the explinations 
> aren't done very carefully.
>
yes, the devil is in the details.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ