On 2018-04-02 09:33, John Johansen wrote: > 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. > Thanks for the answer!
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
