linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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, 9 Jun 2007 13:06:06 -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 12:46:40, david@...g.hm wrote:
> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> Typical "targetted" policies leave all user logins as  
>> unrestricted, adding security for daemons but not getting in the  
>> way of users who would otherwise turn SELinux off.  On the other  
>> hand, a targeted policy has a "trusted" type for user logins which  
>> is explicitly allowed access to everything.
>
> Ok, it sounds as if I did misunderstand SELinux. I thought that by  
> labeling the individual files you couldn't do the 'only restrict  
> apache' type of thing.
>
>> That said, if you actually want your system to *work* with any  
>> default-deny policy then you have to describe EVERYTHING anyways.   
>> How exactly do you expect AppArmor to "work" if you don't allow  
>> users to run "/bin/passwd", for example.
>
> for AA you don't try to define permissions for every executable,  
> and ones that you don't define policy are unrestricted.
>
> 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.

On the other hand, I seem to recall that typical "targeted" policies  
don't grant most of the additional access via access rules, they  
instead add a special case to the fundamental "constraints" in the  
policy (IE: If the subject type has the "trusted" attribute then skip  
some of the other type-based checks).

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/