| === chris14_ is now known as chris14 | ||
| ahasenack | hi security, do you have an opinion on allowing rsyslog write access to /dev/console? See https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2009230 | 17:39 |
|---|---|---|
| -ubottu:#ubuntu-security- Launchpad bug 2009230 in rsyslog (Ubuntu Lunar) "AppArmor denials for rsyslog" [Undecided, New] | 17:39 | |
| ahasenack | and on the topic of consoles, what about including the consoles abstraction? It also allows ttys and pts | 17:39 |
| ahasenack | there is even an example in the shipped rsyslog config file from ubuntu showing how to log certain messages to a tty, so you would just have to ctrl-shift-8 and see certain logs in tty8, for example. This is currently blocked by the rsyslog apparmor profile | 17:40 |
| ahasenack | in the case of that very particular bug, the google-compute-engine could ship an apparmor snippet in /etc/apparmor.d/rsyslog.d to allow /dev/console, and it would work. But if it's something others might do too, and there are no security downsides, maybe we should have that rule (and tty?) in the default rsyslog package | 17:42 |
| jjohansen | ahasenack: so generally speaking consoles are a mess and it is definitely safer to block. With that said, if you are going to allow them, I would do it via the console abstraction, we have plans on improving the console mediation and if you use the abstraction you will pick up those improvements automatically. | 19:11 |
| jjohansen | Also general philosophy here is, if there feature is needed allow it, because otherwise people will disable the profile/apparmor and that is far worse than a looser mediation | 19:11 |
| ahasenack | the only worry I had with the console abstraction was the /dev/pts access, there is a comment above it saying this also allows "access" to xterms and the like | 19:12 |
| ahasenack | unsure what you would get with that: read every keystroke? | 19:12 |
| ahasenack | that being said, rsyslog doesn't run as root, so more would be needed for it to be able to access ttys and ptss | 19:13 |
| jjohansen | right | 19:13 |
| ahasenack | and the console abstraction currently only allows (of the ttys) /dev/tty, not /dev/tty[0-9] | 19:14 |
| ahasenack | is that on purpose, or an oversight? | 19:14 |
| jjohansen | on purpose | 19:14 |
| ahasenack | what does /dev/tty mean again? Please refresh my memory :) | 19:15 |
| ahasenack | the "current" console? | 19:15 |
| jjohansen | yeah | 19:15 |
| jjohansen | its essentially a hardlink for the active processes console, so it is more restricted than say /dev/tty[0-9] | 19:17 |
| georgiag | in the specific case of bug 2009230, the ideal scenario would be to change the rsyslog config file of google-compute-engine to log into a file instead of using /dev/console, but I don't know if that's feasible for them | 19:17 |
| -ubottu:#ubuntu-security- Bug 2009230 in rsyslog (Ubuntu Lunar) "AppArmor denials for rsyslog" [Undecided, New] https://launchpad.net/bugs/2009230 | 19:17 | |
| ahasenack | georgiag: I think the console in a cloud image might be more "important" | 19:18 |
| ahasenack | as you wouldn't ahve access to such a file if the image doesn't get to a point where you can ssh in | 19:18 |
| ahasenack | but the cloud api usually has a way to get the console | 19:18 |
| jjohansen | tty is associated with the process group, tty0 to the virtual terminal | 19:18 |
| georgiag | ah, that's right | 19:19 |
| jjohansen | yeah, adding console access is the way to go | 19:19 |
| ahasenack | you still think the abstraction is best? | 19:19 |
| ahasenack | your improvements won't land in lunar in time for the release, right? | 19:19 |
| jjohansen | true, so maybe just stick to /dev/console | 19:20 |
| jjohansen | the use console abstraction is kind of an upstream thing, where we are trying to get policy to be ready for new features | 19:21 |
| ahasenack | georgiag: was that all that was needed? I see /dev/console is root:tty and only writable by root or tty | 19:21 |
| ahasenack | I've seen other bugs fly past about syslog not being part of the tty group. Maybe the google package is also changing that? | 19:21 |
| ahasenack | or perhaps /dev/console there has different permissions | 19:22 |
| georgiag | I'll have to double check, sorry | 19:27 |
| jjohansen | hrmmm, I don't know either, will be interested to find out | 19:27 |
| ahasenack | anyway, apparmor is definitely in the way | 19:27 |
| ahasenack | but they might find out that after apparmor allows the access, then filesystem permissions are in the way :) | 19:28 |
| ahasenack | georgiag: would you like to propose an MP for rsyslog? I can sponsor | 19:28 |
| ahasenack | (thinking about you getting upload karma). If not, I can do it | 19:28 |
| georgiag | ahasenack: yeah, I'll ping you when I have it ready. thanks | 19:36 |
| ahasenack | georgiag: remember this Monday is beta freeze | 19:37 |
| ahasenack | (I'll be around during the weekend, though) | 19:38 |
| georgiag | okay. thanks for the reminder! | 19:38 |
| UnivrslSuprBox | I noticed that USN-5966-1 was released to xenial/trusty-security/updates, but its revert was only released into ESM. I'm not sure if the team is planning to send the revert to the public archives or kick the package version out of xenial, but this could cause a bad time for the unsupported releases | 20:50 |
| sarnold | UnivrslSuprBox: ack, thanks | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!