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

[John Johansen]

On 07/06/2012 04:40 PM, Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 6. Juli 2012 schrieb John Johansen:
>> On 07/06/2012 03:18 PM, Christian Boltz wrote:
>>> 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
> 
> Indeed ;-)
> (Sometimes I wish Linux would only support "normal"/"sane" filenames - 
> but obviously people like it if they can do funny things, for example 
> https://bugzilla.novell.com/show_bug.cgi?id=757393 )
> 
>>> Just curious - how would that profile name look as filename for
>>> /etc/apparmor.d/ ? Hmm, let's try...
> [...]
>>> 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
> 
> Ah, that explains it ;-)
> 
> [...]
>> heh again not surprising, we should open a bug
> 
> Done - https://bugs.launchpad.net/apparmor/+bug/1021967
> 
>> 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 (" '
>> ..)
> 
> What about using a whitelist with allowed chars and replacing everything 
> else? Blacklists tend to miss (at least) one thing that will explode 
> later...
> 
I'm hesitant on the whitelist approach because of foreign language character
encoding. Most of them respect the basic ascii character but there are a
whole bunch of characters we really can't know at the kernel level.

Of course that could be an arguement for doing it, but I dislike making the
name mangling useless for foreign languages

>>> 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 
> 
> No cheating please ;-)
>
hehe, thats not cheating its just changing the ground rules :-D

>> but in the case where it isn't
>>
>> 123-**
>>
>> wouldn't be too bad, admittedly using globbing/regex special chars is
>> a little scarry. 
> 
> "a little"?!? Are you joking?
> 
Well no, perhaps a little understated, and yes I would expect it could
break non apparmor tools, but I would really hope we test the apparmor
ones.

Overall * is more scary than . since it is both an re and globbing
character but . is an re character (though widely used in filenames). 
Its hard to say where to draw the line

>> We could replace them with something like
>>
>> 123-XX
> 
> That looks MUCH better and will avoid lots of trouble.
> 
okay, I am fine with this

>> or escape them
>>
>> 123-\*\*
> 
> Backslashes in the filename? That makes things extremely funny because 
> you then have to escape the backslashes _and_ the * char. In the shell, 
> you'll probably end up with something like (untested)
> 123-\\\*\\\*
> 
> Do you still like this idea? *eg*
> 
It is my least favorite of the suggestions. Basically I am willing to
go with any of them or perhaps something else, as long as it is some
what sane, and adds value to the user.  However if it to much effort or
edits out too much then I don't see a point in doing it and we might as
well go back to the sid based dir name.


>> I don't really have a preference they each have their problems.
> 
> IMHO not replacing special chars will cause a bigger set of problems 
> (at least if your target is not to make all tools reading /sys/ safe 
> regarding the handling of funny[tm] characters in filenames ;-)
> 
> In case you are interested - the attached little script[1] creates some 
> files with funny[tm] filenames. This should give you some ideas how 
> crazy filenames can be...
> 
thanks

> (Feel free to test some of the binaries and scripts you regularly run 
> with those filenames. I wouldn't be too surprised if they break 
> something ;-)
> 
hehe, neither would I :)