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

[John Johansen]

On 07/05/2012 04:09 PM, Seth Arnold wrote:
> On Sun, Jul 1, 2012 at 4:55 AM, Christian Boltz <apparmor at cboltz.de> wrote:
>> I'd vote for a directory name that is more human-readable than the sid
>> ;-)
>>
>> What about using the sid + a readable profile name with non-allowed
>> characters replaced?
>> Example:
>>     42-bin.ping   # sid 42, profile for /bin/ping
>>
>> I'd replace [^a-zA-Z0-9] with dots. This will replace some characters
>> that are allowed in a file name, but IMHO that's better than having
> 
> I generally favor giving the human operators a fighting chance but I'm
> afraid that someone will try to find a mapping between these names and
> the names of the files in /etc/apparmor.d/. Either we should make that
> mapping 100% explicit and use the same names or we should be very
> upfront that the name attached to the sid is for _human_ inspection
> and use and not to be used for automated policy tools. (Though these
> sorts of hints are always somehow forgotten.)
> 
We can't guarentee that it is the same as the file in /etc/apparmor.d/

The kernel never sees the file name, just a set of profiles that may or
may not have been in the same file. The best it could do is apply the
same mapping to the tools apply. However I think Christian is right that
passing through whitespace, etc could be problematic.

As for the policy tools trying to use those names, that would be bad
and we would have to slap ourselves. The profile name already does
not map to the file name, we already have files with multiple profiles.
And it has been stated policy for some time that the file name does not
have to be the same as the profile that its just a convention.

We could just stick with using the sid, but this has bad usability for
the user, as you have to on average look into half of the profile
directories if you are looking for a specific one.

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.

What I was thinking of doing is a broader isgraph() or maybe something
a little more restricted, but wider than isalnum().

I think having the leading number is a clear indication that its not
the same, and I am open to suggestions as to what else we could do.