linux-kernel - Re: [AppArmor 01/41] Pass struct vfsmount to the inode

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, 26 May 2007 22:10:34 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Toshiharu Harada <haradats@...il.com>
Cc:	James Morris <jmorris@...ei.org>, casey@...aufler-ca.com,
	Andreas Gruenbacher <agruen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> 2007/5/27, James Morris <jmorris@...ei.org>:
>> On Sat, 26 May 2007, Kyle Moffett wrote:
>>> AppArmor).  On the other hand, if you actually want to protect  
>>> the _data_, then tagging the _name_ is flawed; tag the *DATA*  
>>> instead.
>>
>> Bingo.
>>
>> (This is how traditional Unix DAC has always functioned, and is  
>> what SELinux does: object labeling).
>
> Object labeling (or labeled security) looks simple and straight  
> forward way, but it's not.
>
> (1) Object labeling has a assumption that labels are always  
> properly defined and maintained. This can not be easily achieved.

That's a circular argument, and a fairly trivial one at that.  If you  
can't properly manage your labels, then how do you expect any  
security at all?  If you can't manage your "labels", then pathname- 
based security won't work either.  This is analogous to saying  
"Pathname-based security has an assumption that path-permissions are  
always properly defined and maintained", which is equally obvious.   
If you can't achieve the first with reasonable security, then you  
probably can't achieve the second either.  Also, if you can't manage  
correct object labeling then I'm very interested in how you are  
maintaining secure Linux systems without standard DAC.

> (2) Also, assigning a label is something like inventing and  
> assigning a *new* name (label name) to objects which can cause flaws.

I don't understand how assigning new attributes to objects "can cause  
flaws", nor what flaws those might be; could you elaborate further?   
In particular, I don't see how this is really all that more  
complicated than defining additional access control in  
apache .htaccess files.  The principle is the same:  by stacking  
multiple independent security-verification mechanisms (Classical UNIX  
DAC and Apache permissions) you can increase security, albeit at an  
increased management cost.  You might also note that ".htaccess"  
files are yet another form of successful "label-based" security; the  
security context for a directory depends on the .htaccess "label"  
file found within.  The *exact* same principles apply to SELinux: you  
add additional attributes backed by a simple and powerful state- 
machine.  The cross-checks are lower-level than those from .htaccess  
files, but the principles are the same.

Cheers,
Kyle Moffett

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