Comment 10 for bug 1117804

Revision history for this message
John Johansen (jjohansen) wrote :

responding to @intrigeri (sorry this got lost some how).

tldr: yes we are basically on the same page.

AppArmor does not fit into the 1400 range formats, every one of our messages have some custom fields. Some of them could be reformated/reworked to share more, but we would still need custom fields.

Our message fields are in the common name=value format. So in that sense they do fit in.

Kernel side this is fairly easy, we use common lsm_audit for the messages we share in common, the code provides a callback to add your own fields. Basically all that is needed is patch to allow different number ranges to be used.

Userspace there needs to be some patching so LSM specific fields are known about.

Whether is best to allocate new fields in a single number (say 1500), with no fixed number of fields to output or it better to split into a range of based on message type, I am not picky. When 1500 was taken away from us I think it was 1500-1505 that we used, but expect we wouldn't use the same mappings today if we had a choice.

so we have the generic audit type that is carried { audit, allowed, denied, killed, prompt, hint, status, error }

this could carried as a common field, or we could use an allocated block for

we have rule class, which is another way things are broken down, its things like { file, cap, network, dbus, ...} there are currently about 25 of them currently.

common fields that can occur within apparmor messages { operation, info, error, namespace, profile, label }, some fields aren't output if not needed. Eg. we are auditing an access to say /etc/shadow that is allowed but we want an audit trail for error won't be output, if its a system status message that is not generated by a profiles rule set, profile= won't be used. This set does not lend itself to an audit range as they each take on basically a string value.

Then within a given class there are set of fields, some of them are shared by several classes, but not all, and there are some that are only used by a single class. Some examples would be, most mediation class share requested= and denied= the values are class depended even those may be shared by a subset of classes.