On Wed, 10 Apr 2019, daniel curtis wrote: > Hello Mr Strandboge. > > First of all, I would like to thank You for your answer. Based on your > suggestions, I will add an 'owner' prefix to the rules etc. However, I > don't know what to do with rules for '/run/systemd/private' and 'net_admin' > capability, because You've written, that: "these two are getting into an > area where you are giving logrotate device ownership, since systemctl is > very rich." So, leave or deny'ing? > > Can You provide some more informations? Should these rules be there? (I > will try to make some test and check if above rules are really needed).
I can't say that the rules aren't needed. I suspect they are since logrotate is in the business of restarting things. My point is that systemd is not designed with application isolation in mind, so there is no way to simply say "grant systemctl the ability to restart services, but nothing else". Between that and the ptrace (trace) rule, the AppArmor policy can at most be advisory and cannot enforce that an attacker-controlled logrotate can't take over the system. > If it's about '/run/dbus/system_bus_socket' rule: you're probably right and > if - for example - Mr Christian Boltz will decide to update exisiting > Logrotate profile, He will - probably - use 'dbus-strict' abstraction. > (However, I rather dont want to use 'abstractions' when only one rule is > okay and the rest aren't needed, but that's only my opinion). It is not since AppArmor has dbus mediation on systems that have compiled dbus-daemon with apparmor support. Therefore if you: #include <abstractions/dbus-strict> then dbus-daemon will ask the kernel if rules related to DBus bus name, path, interface and method are allowed. You likely want dbus-strict because it only gives access for the most basic queries that are needed by anything that communicates over the DBus system bus. You would need to add other policy for actually communicated with a particular service. > >> Does the ptrace show up if you have all the other rules? (...) > > Sorry, Mr Strandboge, but I don't understand. Do You mean a log files and > e.g. "DENIED" entries? Let see: when I decided to block 'ptrace' rules and > added all rules mentioned in my first message, no - 'ptrace' does not show > as a - for example - "DENIED" logs etc. As I mentioned already; when > 'rsyslog' package has been updated, log files rotation was broken, log > files were empty and so on. If you add all the rules you suggested, but not any ptrace rules, I was curious if there was still a ptrace denial. > By the way: when Mr Christian Boltz updated Logrotate profile (see 1.), > there was two 'abstractions': 'bash' and 'nameservice'. I noticed, that in > my case it's 'base' and 'bash'. Strange. Which one 'abstractions' should be > used? (Please note, that 'base' abstractions contains 3. 'ptrace' rules). > So, which 'abstractions' should be used? Can You check this? Of course, if > you're using Logrotate profile. We typically recommend all profiles include the 'base' abstraction, but you're free to do what you want of course. While there are ptrace rules in the base abstraction, they are deemed safe and importantly *not* 'ptrace (trace)'. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: PGP signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
