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]

Message-ID: <Pine.LNX.4.64.0706090930380.6313@asgard.lang.hm>
Date:	Sat, 9 Jun 2007 09:46:40 -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 01:18:40, david@...g.hm wrote:
>> SELinux is like a default allow IPS system, you have to describe EVERYTHING 
>> to the system so that it knows what to allow and what to stop.
>
> WRONG.  You clearly don't understand SELinux at all.  Try booting in 
> enforcing mode with an empty policy file (well, not quite empty, there are a 
> few mandatory labels you have to create before it's a valid policy file). 
> /sbin/init will load the initial policy, attempt to re-exec() itself... and 
> promptly grind to a halt.  End-of-story.

sigh,
   two paragraphs below what you quoted I acknowledged exactly what you 
state. however since you must tag everything before you turn on any 
security it seems to me that you have to define everything, which is a 
similar amount of work as you would have to do for a default allow policy.

> 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

is this correct?

David Lang

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