Message-Id: <D5D584BB-21D0-4BBA-B70E-FCBA07960646@mac.com>
Date:	Sat, 9 Jun 2007 15:50:38 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	david@...g.hm
Cc:	Greg KH <greg@...ah.com>, Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Pavel Machek <pavel@....cz>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

On Jun 09, 2007, at 13:32:05, david@...g.hm wrote:
> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> On Jun 09, 2007, at 12:46:40, david@...g.hm wrote:
>>> so as I understand this with SELinux you will have lots of labels  
>>> around your system (more as you lock down the system more) you  
>>> need to define policy so that your unrestricted users must have  
>>> access to every label, and every time you create a new label you  
>>> need to go back to all your policies to see if the new label  
>>> needs to be allowed from that policy
>>
>> Actually, it's easier than that.  There are type attributes which  
>> may be assigned to an arbitrary set of types, and each "type"  
>> field in an access rule may use either a type or an attribute.  So  
>> you don't actually need to modify existing rules when adding new  
>> types, you just add the appropriate existing attributes to your  
>> new type.  For example, you could set up a "logfile" attribute  
>> which allows logrotate to archive old versions and allows audit- 
>> admin users to modify/delete them, then whenever you need to add a  
>> new logfile you just declare the "my_foo_log_t" type to have the  
>> "logfile" attribute.
>
> isn't this just the flip side of the same problem?
>
> every time you define a new attribute you need to go through all  
> the files and decide if the new attribute needs to be given to that  
> file.

No you don't, you can add attributes to a type after-the-fact.  In  
concept this problem is very similar to programming:  You have  
various documented interfaces used by different policy files to  
interact with each other.  As long as your policy files conform to  
the documented interfaces then you *DONT* have to manually inspect  
each file because you can make basic assumptions.  On the other hand,  
when you break that interface "contract" you will get very unexpected  
results.  For the above example:

My syslog policy file would create a "logfile" attribute and types  
for "/var/log/auth/auth.log", "/var/log/kern/kern.log", and "/var/log/ 
messages".  It would also create a "logdaemon" attribute which has  
automatic type transitions to create files in different "/var/log/*"  
directories  Finally, it would allow the syslogd type to create and  
append to its specific file types for "auth.log", "kern.log", and  
"messages".

My logrotate policy file would depend on the syslog policy and would  
declare the logrotate daemon type as a "logdaemon", and additionally  
allow logrotate to read, rename, append, and delete "logfile" types.   
Since logrotate is a "logdaemon", it already has the appropriate type  
transitions for new types.

My samba policy file would depend on the syslog policy and would  
declare the samba daemon type as a "logdaemon" and the "/var/log/ 
samba/*" type as a "logfile".  Then it would add a type transition  
rule so when "logdaemon" creates new files in "samba_log_dir_t", they  
have the appropriate "samba_log_t" label.  Finally, samba would allow  
itself to append to "samba_log_t" files.

Note that now when "logrotate" runs and rotates files in /var/log/ 
samba, it will automatically create the new files with type  
"samba_log_t", even though there are no *direct* associations between  
those types.  If the syslog policy file was poorly written it could  
seriously adversely affect the security of the system, but hopefully  
that's obvious :-D.  Policy development is _hard_, it's a whole  
separate state-machine and pseudo-programming-language that should  
mostly be left to security professionals or very experienced  
developers/sysadmins.

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/

Powered by blists - more mailing lists