> 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. Well, if i'm writing a malware i'll make sure it uses systemd-run so it keeps on running. > > > > 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? Nothing, because this is not the proper solution to the security problem. > > > 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. > > This default is nonsense the only thing that it really does is break stuff that relies on processes being executed after the user closes his session. Yes, there's an obscure systemd-run command that only the systemd devs know and can make your programs run forever but what's wrong with "&" or just running "screen" to create a persistent session?? I know you're gonna start with the "there's been 40 years since Unix was designed" argument, Unix was designed with simplicity in mind, this default is not simple it adds another layer of complexity that is not really needed, breaks stuff and makes ALL THE WORLD change the way they work. Going back to the bank example, the change of KillUserProcesses should be decided by the security team or the system administrator instead of magically be there. And no, the argument of "you should learn systemd" does not apply here, this changes the way Linux behaves and it's not obvious to the user and believe me nobody outside of the people that have their eyes on systemd reads this document: https://github.com/systemd/systemd/blob/master/NEWS#L29 The change of KillUserProcesses to "yes" should be done in a use case basis not the upstream dev team, this changes the way Linux behaves in a very aggressive way and can lead to a lot of bug reports, break scripts and could make people stop using Linux with systemd because you should not break the "least surprise" principle. It's easier to remove just one commit [1] than to make EVERYBODY change the way they work... Cheers, Ivan [1] https://github.com/systemd/systemd/pull/3005/commits/97e5530cf2076a2b4fc55755917262607aaa6338 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
