Re: Upcoming change: rsyslog's apparmor enforced by default
Hi Steve, On Sun, Feb 12, 2023 at 2:48 AM Steve Langasek wrote: > > Hi Andreas, > > On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote: > > Hi, > > > In the next few days, if all goes according to plan, I'll upload > > rsyslogd to lunar with a change[1] to the way its apparmor profile is > > applied. > > > The confinement status won't be changed during upgrades, but fresh > > installs will have the apparmor profile enforced by default. Up until > > now, it's been disabled. > > Can you elaborate on this decision not to change the behavior on upgrade? > It's expected on upgrade between releases that behavior will change; and to Hmm, you are right, I was thinking in the context of lunar to lunar upgrades, and not release upgrades, which is what we are aiming for. > not enforce for upgrading users means a difference in configs between new > installs and upgrades that complicates the support matrix over the long > term. > > I am strongly in favor of making the behavior on upgrade conform to the > behavior on new installs - even if that means there might be some unpleasant > surprises where the package fails to configure because of apparmor being > enabled. That seems unlikely to me in any case; even if the user has > diverged from the stock rsyslog config, it seems more likely to me that the > daemon would still start up but might in some cases fail to log. Again, Correct, I'm not failing the startup because apparmor failed to apply or load, and that is in line with current rsyslog's behavior towards its plugins. If a plugin fails to write a log (like mysql is not available, or apparmor prevented it from doing so), it will just keep retrying in the background, instead of failing the whole daemon or the logging to other places. I'll make the change, thanks for the feedback! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Upcoming change: rsyslog's apparmor enforced by default
Hi Andreas, On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote: > Hi, > In the next few days, if all goes according to plan, I'll upload > rsyslogd to lunar with a change[1] to the way its apparmor profile is > applied. > The confinement status won't be changed during upgrades, but fresh > installs will have the apparmor profile enforced by default. Up until > now, it's been disabled. Can you elaborate on this decision not to change the behavior on upgrade? It's expected on upgrade between releases that behavior will change; and to not enforce for upgrading users means a difference in configs between new installs and upgrades that complicates the support matrix over the long term. I am strongly in favor of making the behavior on upgrade conform to the behavior on new installs - even if that means there might be some unpleasant surprises where the package fails to configure because of apparmor being enabled. That seems unlikely to me in any case; even if the user has diverged from the stock rsyslog config, it seems more likely to me that the daemon would still start up but might in some cases fail to log. Again, behavior changes are expected across release upgrades. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Upcoming change: rsyslog's apparmor enforced by default
Hi, In the next few days, if all goes according to plan, I'll upload rsyslogd to lunar with a change[1] to the way its apparmor profile is applied. The confinement status won't be changed during upgrades, but fresh installs will have the apparmor profile enforced by default. Up until now, it's been disabled. A summary is in the README.apparmor[2] file, and d/NEWS was also updated/created. I tried a mix of fixed and dynamic profile snippets, and packages can install their own snippets if needed. These would usually be packages that alter the rsyslog configuration to log somewhere else where the normal apparmor profile would have denied that, but at the same time we don't want to allow that by default if it's not needed. There are a few more use cases I would like to tackle, including more test cases, and the `omprog` plugin is an obvious one. This is not yet covered, and I hope to get more data about its usage before coming up with a solution. It's hard to try to detect its usage in the config file because the config can be in so many different formats. Maybe we can come up with generic sandbox of some sort for binaries used with the omprog plugin, or maybe we will just have to leave users to adjust that via the existing /etc/apparmor.d/local/usr.sbin.rsyslogd mechanism. This adds a lot of delta to the package, at least in line count, but I don't think it's hard to maintain. I'll also of course try to submit this to debian, once we settled on the approach in lunar. 1. https://code.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/+git/rsyslog/+merge/436955 2. https://git.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/tree/debian/README.apparmor?h=lunar-rsyslog-enable-apparmor-dep8-take4-dot-d -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
