[apparmor] [Patch 0/1] RFC: apparmor profile directory

[John Johansen]

On 07/06/2012 03:18 PM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 5. Juli 2012 schrieb John Johansen:
>> The best it could do is apply the same mapping to the tools apply. 
> 
> Sounds like a good idea, but it doesn't cover everything ;-) (see below)
> 
>> However I think Christian is
>> right that passing through whitespace, etc could be problematic.
> 
> There are other characters that can also cause some "funny effects"[tm] 
> ;-)
sure there are a whole host of characters that could be interpreted in
strange ways

> 
>> What I like about Christians proposal is it guarentees the ids are
>> unique and different by prepending the sid but also gives the user a
>> usable name to guide them.
>>
>> However I don't think using just alphanumeric values will be enough as
>> it makes unamed profiles like /** { } real ugly.
> 
> Just curious - how would that profile name look as filename for 
> /etc/apparmor.d/ ? Hmm, let's try...
> 
> # aa-genprof '/**'
> /** does not exist, please double-check the path.
> 
> OK, I'm feeling adventurous ;-)
> 
> # touch '/**'
> # aa-genprof '/**'
> 
> The result was the file /etc/apparmor.d/** with 
> /** flags=() { ... }
> 
> In other words: genprof doesn't seem to replace any special character. 
> Maybe it better should :-/
> 
heh, not surprising, as it has been lagging in feature support since 2.3
I know I didn't get to updating it when I initially added support to the
parser for profile name globbing

> It should probably also do some escaping in the profile name. My example 
> was a bit ;-) extreme, but imagine someone is crazy enough to have a 
> binary called '/bin/b*' and wants to create a profile for it (which is 
> basically a good idea with such a filename ;-)
> 
yes it should :/

> The result will be a profile for '/bin/b*' which includes things like 
> /bin/bash... Do I need to say more? ;-)
> 
> (needless to say that I practised unloading the /** profile via the 
> /sys/kernel/security/apparmor/.remove interface afterwards because it 
> was the only working option ;-)
> 
heh again not surprising, we should open a bug

>> What I was thinking of doing is a broader isgraph() or maybe something
>> a little more restricted, but wider than isalnum().
> 
> I prefer the "better safe than sorry" way ;-) - therefore I don't think 
> isgraph() (anything except whitespace) is a good idea. I know it might 
> look ugly if we replace too many characters, but looking ugly is much 
> better than breaking tools that read /sys/ ;-)
> 
I am not opposed to replacing more characters, the current implementation
(not yet posted) is a little more straight isgraph(), replacing WS with _
and / with ., and just dropping a few others (" ' ..)

> That all said - what do you think how the /sys/ entry/directory for the 
> /** profile should be named?
> 
Well ideally the profile would have a specified name, ie

profile default /** { }

so that "default" is used but in the case where it isn't

123-**

wouldn't be too bad, admittedly using globbing/regex special chars is a
little scarry. We could replace them with something like

123-XX

or escape them

123-\*\*


I don't really have a preference they each have their problems.