On Thursday, June 02, 2016 13:04:44 Lennart Poettering wrote: > On Wed, 01.06.16 07:20, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) 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. > > 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. 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. Then what prevents the user from keeping a session forever? > 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. What exactly do you mean by "logged him out"? You must be a privileged user to do that. If you are a privileged user, killing his/her processes is just one more command on top of that... Kamil > 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. > > Lennart -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
