On Thu, 2016-06-02 at 13:04 +0200, Lennart Poettering wrote: > On Wed, 01.06.16 07:20, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote: > > > > > > Any scheme that relies on unprivileged programs "being nice" doesn't > > > fix the inherent security problem: after logout a user should not be > > > able consume further runtime resources on the system, regardless if he > > > does that because of a bug or on purpose. > > > > I don't think you've yet explained exactly why this constitutes a > > 'security problem'. Could you please do so? > > Well. Let's say you are responsible for the Linux desktops of a large > security-senstive company (let's say bank, whatever), and the desktops > are installed as fixed workstations, which different employees using > them at different times. They log in, they do some "important company > stuff", and then they log out again. Now, it's a large company, so it > doesn't have the closest control on every single employee, and > sometimes employees leave the company. Sometimes even the employees > browse to the wrong web sites, catch a browser exploit and suddenly > start runing spam bots under their user identity, without even > knowing.
These are all bad things, yes. Yet there is a large logic gap right here. > In all of these cases you really want to make sure that whatever the > user did ends – really ends – by the time he logs out. Er...why? Why is it OK for the employee to be running malicious code (spambots, rootkits, whatever you like) just so long as they're logged in? How is making sure the evil code only runs while the employee is logged in helping in any significant way? > So that the > employee can't do stuff there except when logged in, and that he can't > do stuff there even long after he left the company, and that the spam > bot he caught gets killed as soon as he logs out. I guess a spambot that only runs 9-5 is slightly better than one that runs 24x7, but it hardly seems like the ideal fix for the problem. As for 'after he left the company', well, killing everyone's processes every time they log out is an awfully large hammer to solve the problem of killing someone's processes the *one time* they leave the company. > This is really just one example. This model I think really needs to be > the default everywhere. On desktops and on servers: unless the admin > permitted it explicitly, there should not be user code running. If you > allow your intern user access to a webserver to quickly check our the > resource consumption of some service that doesn't mean that he shall > be allowed to run stuff there forever, just because he once had the > login privilege for the server. And even more: after you disabled his > user account and logged him out, he really should be gone. > > Yes, UNIX is pretty much a swiss cheese: it's really hard to secure a > system properly so that somebody who once had access won't have access > anymore at a later point. However, we need to start somewhere, and > actually defining a clear lifecycle is a good start. > > Pretty much all more modern OS designs tend to have such a clear > lifecycle btw: when the user is logged out, he's *really* logged > out. And it's completely OK if certain users get excludeded from that, > but if so, then the admin needs to sign off on that, and thus a > privilege check needs to be enforced. I think the design has a lot to be said for it, especially if you're starting from scratch and don't have decades of existing expectations and workflows to deal with. But I'm not hugely convinced by the 'security' aspect of it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
