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 10:32:05 -0700 (PDT)
From:	david@...g.hm
To:	Kyle Moffett <mrmacman_g4@....com>
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 Sat, 9 Jun 2007, Kyle Moffett wrote:

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

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.

David Lang

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