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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1117804
Title:
ausearch doesn't show AppArmor denial messages
Status in AppArmor:
Confirmed
Status in audit package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Incomplete
Bug description:
The following command should display all AVC denials:
ausearch -m avc
However, it doesn't work with AppArmor denials. Here's a quick test
case to generate a denial, search for it with ausearch, and see that
no messages are displayed:
$ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current
cat: /proc/self/attr/current: Permission denied
$ sudo ausearch -m avc -c cat
<no matches>
ausearch claims that there are no matches, but there's a matching
audit message if you look in audit.log:
type=AVC msg=audit(1360193426.539:64): apparmor="DENIED"
operation="open" parent=8253 profile="/usr/sbin/tcpdump"
name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
