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.0706082356220.6675@asgard.lang.hm>
Date:	Sat, 9 Jun 2007 00:04:15 -0700 (PDT)
From:	david@...g.hm
To:	Sean <seanlkml@...patico.ca>
cc:	Tetsuo Handa <from-lsm@...ove.SAKURA.ne.jp>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname
 matching

On Sat, 9 Jun 2007, Sean wrote:

>> so are you suggesting that SELinux would call out to userspace for every
>> file open to get the label for that file?
>>
>
> No, i'm not.  You must already have a kernel function in the current
> implementation of AA that decides the proper policy for each path.  Why
> not use it  to feed labels into SELinux.

if it was this easy just have SELinux set the label == path

you first need to figure out what the path is. right now this can't be 
done, the AA paches provide this capability.

second, the AA policies aren't based just on the path, they are based on 
the program accessing the path, then the path. you can have two different 
policies for two different programs accessing the same path, but for most 
programs (although, not nessasarily most activity) there will be no 
policy, and therefor no need to check the path.

but even if you did these things, why would it be an advantage to use a 
mechanism to create a dummy label and pass it off to different code rather 
then just decideing at that point? once the AA code knows what the policy 
for this path is for this program (which it would need to know to set the 
label) how is it a win to pass this off to another chunk of code? you 
would also need to make sure that the SELinux code didn't try to cache the 
label for future use either, becouse in the future the access may be from 
another program and so the policy that's needed is different.

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/