Re: [apparmor] [profile] logrotate: new rules needed.
Hello.I'm sorry for such a long time without answer. So, after five, six daysof tests based on the removal (hashing) some rules e.g. 'ptrace', itturned out, that these rules are needed. Firstly, after removing rules,everything was okay - log files were rotated, informations logged etc.However, today I noticed exactly the same symptoms, which I describedin my first mail: '/var/log/syslog' file was empty all the time -nothing has been logged during the whole User session and so on.Additionaly, there was a plenty of the same "DENIED" messages (see myfirst mail). So, the situation has been repeated.Mr Jamie Strandboge, you had asked about 'ptrace' rule:>> Does the ptrace show up if you have all the other rules? (...)>> I was curious if there was still a ptrace denial.When 'ptrace' rule (and these for 'net_admin' capability,'/run/systemd/private' and '/run/dbus/system_bus_socket' files) wasremoved/hashedthere was not any "DENIED" entries and logrotate works as always -automatic rotation and compression of log files etc. Until today.So, what do you think about all these rules? Are they okay and secureto use? Maybe there is another way to handle this? But, I see, thatthere are some doubts. (I mean Mr Strandboge and Mr Arnold answers).Thanks, best regards.-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [profile] logrotate: new rules needed.
Hello. I'm sorry for such a long time without answer. So, after five, six days of tests based on the removal (hashing) some rules e.g. 'ptrace', it turned out, that these rules are needed. Firstly, after removing rules, everything was okay - log files were rotated, informations logged etc. However, today I noticed exactly the same symptoms, which I described in my first mail: '/var/log/syslog' file was empty all the time - nothing has been logged during the whole User session and so on. Additionaly, there was a plenty of the same "DENIED" messages (see my first mail). So, the situation has been repeated. Mr Jamie Strandboge, you had asked about 'ptrace' rule: >> Does the ptrace show up if you have all the other rules? (...) >> I was curious if there was still a ptrace denial. When 'ptrace' rule (and these for 'net_admin' capability, '/run/systemd/private' and '/run/dbus/system_bus_socket' files) was removed/hashed there was not any "DENIED" entries and logrotate works as always - automatic rotation and compression of log files etc. Until today. So, what do you think about all these rules? Are they okay and secure to use? Maybe there is another way to handle this? But, I see, that there are some doubts. (I mean Mr Strandboge and Mr Arnold answers). Thanks, best regards. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [profile] logrotate: new rules needed.
Hello. I'm sorry for such a long time without answer. So, after five, six days of tests based on the removal (hashing) some rules e.g. 'ptrace', it turned out, that these rules are needed. Firstly, after removing rules, everything was okay - log files were rotated, informations logged etc. However, today I noticed exactly the same symptoms, which I described in my first mail: '/var/log/syslog' file was empty all the time - nothing has been logged during the whole User session and so on. Additionaly, there was a plenty of the same "DENIED" messages (see my first mail). So, the situation has been repeated. Mr Jamie Strandboge, you had asked about 'ptrace' rule: >> Does the ptrace show up if you have all the other rules? (...) >> I was curious if there was still a ptrace denial. When 'ptrace' rule (and these for 'net_admin' capability, '/run/systemd/private' and '/run/dbus/system_bus_socket' files) was removed/hashed there was not any "DENIED" entries and logrotate works as always - automatic rotation and compression of log files etc. Until today. So, what do you think about all these rules? Are they okay and secure to use? Maybe there is another way to handle this? But, I see, that there are some doubts. (I mean Mr Strandboge and Mr Arnold answers). Thanks, best regards. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [profile] logrotate: new rules needed.
On Wed, 10 Apr 2019, Seth Arnold wrote: > On Wed, Apr 10, 2019 at 06:31:59PM +, daniel curtis wrote: > > Two years ago, Mr Seth Arnold, Mr Christian Boltz and I, started to work on > > Logrotate profile updates, because profile, which was then available did > > not have many necessary rules etc. However, We managed to achieve a > > satisfactory result (see 1.) > > Hello Daniel, > > > # apparmor="DENIED" operation="open" > > # profile="/etc/cron.daily/logrotate" > > # name="/proc/sys/kernel/osrelease" comm="systemctl" > > # requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > > I think a mistake was made here, and it influenced nearly everything > beyond this point. systemctl should not be an 'ix' rule. It requires way > more privileges for it to do its work than logrotate needs to do its work. > > Cx, maybe. Ux, maybe. But ix is setting yourself up for adding so many > privileges to logrotate that the profile isn't actually confining > logrotate much. It's just a maintenance hassle. and my greater point is that a Cx or Ux results in not confining logrotate much either. -- 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
Re: [apparmor] [profile] logrotate: new rules needed.
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 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
Re: [apparmor] [profile] logrotate: new rules needed.
On Wed, Apr 10, 2019 at 06:31:59PM +, daniel curtis wrote: > Two years ago, Mr Seth Arnold, Mr Christian Boltz and I, started to work on > Logrotate profile updates, because profile, which was then available did > not have many necessary rules etc. However, We managed to achieve a > satisfactory result (see 1.) Hello Daniel, > # apparmor="DENIED" operation="open" > # profile="/etc/cron.daily/logrotate" > # name="/proc/sys/kernel/osrelease" comm="systemctl" > # requested_mask="r" denied_mask="r" fsuid=0 ouid=0 I think a mistake was made here, and it influenced nearly everything beyond this point. systemctl should not be an 'ix' rule. It requires way more privileges for it to do its work than logrotate needs to do its work. Cx, maybe. Ux, maybe. But ix is setting yourself up for adding so many privileges to logrotate that the profile isn't actually confining logrotate much. It's just a maintenance hassle. Thanks signature.asc Description: PGP signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [profile] logrotate: new rules needed.
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). 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). >> 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. >> The use of systemctl has me very concerned and begs the question of the utility of the profile since the policy is at best advisory at that point. True, 'systemctl' is... invasive? I don't know if it's a proper word, but it shows as 'comm="systemctl"' in all AppArmor logs (I mean these mentioned by me, after 'rsyslog' update etc.) 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. I'm asking, I'm always trying to not use a "big" 'abstractions', that contains a lot of rules (and that way, give much more access for apps etc. I rather want to use a proper rule/s. Shortly: what is in logs entries, became rule. Of course, there are situations, where allowing some access, even when there is a "ALLOWED/DENIED" entry is not a good idea etc. But that's is different story, completly different story. Apologize for off-top. Okay, I'm a little tired so apologize for any mistakes or stupid, naive questions. Thanks, best regards. _ 1. https://lists.ubuntu.com/archives/apparmor/2016-December/010388.html -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [profile] logrotate: new rules needed.
On Wed, 10 Apr 2019, daniel curtis wrote:
> Hello.
>
> Two years ago, Mr Seth Arnold, Mr Christian Boltz and I, started to work on
> Logrotate profile updates, because profile, which was then available did
> not have many necessary rules etc. However, We managed to achieve a
> satisfactory result (see 1.)
>
> In the meantime - during various tests - it turned out, that three new
> rules are needed. I've written an email, but there was not any answer
> (please see 2.) Rules mentioned in a second link are not available in
> updated Logrotate profile (see 1.)
>
> So, is there a possibility to add these rules? I'm especially asking Mr
> Christian Boltz.
>
> And now very important thing. On Mon., Mar. 25 rsyslog package has been
> updated (see 3.) As we can see in a change list, there are some interesting
> informations about 'rsyslog-rotate'. Then serious problems started to
> happen: log files, such as '/var/log/syslog' were empty all the time and
> nothing logged etc. However, 'syslog.1' file contained some informations
> and this helped me with finding the cause.
>
> It turned out that the reason is obvious: AppArmor blocked operations etc.
> So, below are logs and rules created based on these entries. (NOTE: adding
> these rules helped and everything is okay now; logrotate works as
> expected.)
>
> 1/
> # apparmor="DENIED" operation="exec"
> # profile="/etc/cron.daily/logrotate"
> # name="/usr/lib/rsyslog/rsyslog-rotate" pid=4988
> # comm="sh" requested_mask="x" denied_mask="x"
> # fsuid=0 ouid=0
> #
> /usr/lib/rsyslog/rsyslog-rotate ix,
This is fine.
> 2/
> # apparmor="DENIED" operation="open"
> # profile="/etc/cron.daily/logrotate" name="/proc/2054/stat"
> # comm="systemctl" requested_mask="r" denied_mask="r"
> # fsuid=0 ouid=0
> #
> @{PROC}/[0-9]*/stat r,
Perhaps:
owner @{PROC}/[0-9]*/stat r,
> 3/
> # apparmor="DENIED" operation="open"
> # profile="/etc/cron.daily/logrotate"
> # name="/proc/sys/kernel/osrelease" comm="systemctl"
> # requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> #
> @{PROC}/sys/kernel/osrelease r,
This is fine.
> 4/
> # apparmor="DENIED" operation="open"
> # profile="/etc/cron.daily/logrotate" name="/proc/1/environ"
> # comm="systemctl" requested_mask="r" denied_mask="r"
> # fsuid=0 ouid=0
> #
> @{PROC}/[0-9]*/environ r,
Less great, but this would be somewhat better:
owner @{PROC}/[0-9]*/environ r,
> 5/
> # apparmor="DENIED" operation="open"
> # profile="/etc/cron.daily/logrotate" name="/proc/cmdline"
> # comm="systemctl" requested_mask="r" denied_mask="r"
> # fsuid=0 ouid=0
> #
> @{PROC}/cmdline r,
This is fine.
> 6/
> # apparmor="DENIED" operation="capable"
> # profile="/etc/cron.daily/logrotate" comm="systemctl"
> # capability=12 capname="net_admin"
> #
> capability net_admin,
>
> 7/
> # apparmor="DENIED" operation="connect"
> # profile="/etc/cron.daily/logrotate"
> # name="/run/systemd/private" comm="systemctl"
> # requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
> #
> /{,var/}run/systemd/private rw,
Uh oh, these two are getting into an area where you are giving logrotate device
ownership, since systemctl is very rich.
> 8/
> # apparmor="DENIED" operation="connect"
> # profile="/etc/cron.daily/logrotate"
> # name="/run/dbus/system_bus_socket" comm="systemctl"
> # requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
> #
> /{,var/}run/dbus/system_bus_socket rw,
>
Perhaps just allow:
#include
> And as a last rule: 'ptrace'. This system call can be defined as dangerous
> accesses and should not be allowed in most policy. Is this true? It can be
> abused - for example - to break out of the seccomp sandbox etc. Anyway, it
> seems that after mentioned 'rsyslog' update, logrotate requests 'ptrace
> (trace)' rule. Please see below:
>
> 9/
> # apparmor="DENIED" operation="ptrace"
> # profile="/etc/cron.daily/logrotate" comm="systemctl"
> # requested_mask="trace" denied_mask="trace"
> # peer="unconfined"
> #
> deny ptrace (trace) peer=unconfined,
> #ptrace (trace) peer=unconfined,
Does the ptrace show up if you have all the other rules? Oftentimes ptrace
shows up cause the program crashes and there is some sort of crash handling
going on. It could also be caused by the systemctl command since 'trace' is
unfortunately overloaded. Deny would definitely be better, otherwise this gives
logrotate the access to ptrace unconfined root (aka, another means to device
ownership). That said, deny rules make debugging more difficult since people
can't see why something is failing as easily.
> As we can see, there are two rules. Because of some doubts about 'ptrace'
> call, I decided to make some tests and it seems, that denying 'ptrace
> (trace)' doesn't break anything and logrotate works normally. What is your
> opinion about this rule? Should it be allowed (see second, hashed rule) or
> a better options is to deny such request?
>
> ● By the way: what access mode should be used in rule '1/' concerning
> '/usr/lib/rsyslog/rsyslog-rotate'? Because logs contained
>
