On 03/30/2018 09:23 AM, Mikhail Morfikov wrote: > AppArmor has a feature that allows it to log messages, and that behavior can > be > controlled via /sys/module/apparmor/parameters/audit . But according to some > docs I've found, this logging mechanism is rather limited -- basically logging > can be enabled or disabled for all profiles at the same time. > Unfortunately this is indeed the case atm.
> In some cases, it's really hard to profile an app because it shouldn't access > all files in some example directory. I mean, you can add some exception (path) > in the AppArmor profile for that file, and the rest of the files in the > directory will be denied by default. The problem is that you'll get spam of > the > denied messages in the syslog, and how to deal with this? You can't use > something like the following: > > /dir/file1 rw, > deny /dir/** rw, > > In this case all the files under /dir/ will be denied and no logs will be > printed. The only way to deal with this situation is to deny every single file > under /dir/ (except file1), but sometimes the content of /dir/ can change, and > the task of getting rid of the messages from the syslog is impossible. You > could > probably filter the file somehow, for instance, by extensions, but what when > files don't have any extensions? > yes this is problematic and there is wip to improve this. Specifically there will be some new flags for profile level control, rule qualifiers allowing for better control at individual rules, and there will be some support for boolean operations in policy. Eg. you would be able to write deny /dir/** - /dir/file rw, so that you can deny every thing in a directory except certain files. > I thought I could disable logging for a specific profile using some flags, for > instance: > > ... > /usr/bin/app flags=(nolog) > ... > > So after I create a profile, I would add this flag and don't care whether > something is silently denied for the app, of course till the app works as > expected, and at the same time I would be able to see logs from other > profiles. > But this simply doesn't work. > sadly not yet. There will be some new flags coming, but those will require both kernel and userspace updates. > Other solution I could also think of is to add a rule like the following: > > /dir/file1 rw, > nolog /dir/**, > > In this case, logging would be enabled for the profile itself, but any access > to > files in /dir/ would be silently denied. Of course, the app would have access > to > the files in the directory that are specified in the AppArmor profile. > > Are the logging features possible to implement? > yes, and more. However some changes will require not just changes in userspace but also in the kernel. So some features will only be available on newer userspace + newer kernel, while others will be available with just an update to the userspace. The boolean operations mentioned above and rule specific quieting of audit (noaudit), is possible with just a userspace update. A profile wide noaudit flag is possible from userspace if the compiler turns it into per rule noaudit flags. The only disadvantage here is you would not be able to turn it off per profile (but current kernels don't support doing that so there is no loss for current kernels). > I also wanted to ask about mime types. Files have filenames, but the content > of > a file is independent of the filename or a file path. In this way, when you > don't want the app to access some file based on the path name, AppArmor can > block access to the file. If you change the name of the file, the file doesn't > really have to be denied anymore (could match some rules in the profile), and > the access will be granted. But what about mime types? Basically if a file > has a > "video/x-msvideo" type, AppArmor would deny access to this specific type, and > the app wouldn't be able to open the file no matter where the file is located. > > Is this feature possible to implement in AppArmor, or this can't be done? > It is possible but there are some caveats. First it will greatly depend on where/how the types are stored. If they are tagged on the file in a well known xattr it will be possible in the future to use an xattr conditional match. If however the mime type is derived by an external database or by scanning the file, a userspace helper will be required. AppArmor currently does not support an upcall to a userspace helper but it is a commonly requested feature and it will likely be added at some point. It then would be a matter of extending such a helper to provide the mime type mediation. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
