Lennart Poettering <mzerqung@xxxxxxxxxxx> 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), I suppose a bank might have a policy that the systems that handle the money must not be touched while the bank is closed. Then they might want to kill processes at closing time. That's a rather special use case that should be configured where it's needed, and it seems to me that it should be tied to the bank's opening-hours, not users' login sessions. > 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, But apparently they do trust their employees enough to allow them to log in and run processes. If an employee wants to do something bad, then what prevents them from doing it while sitting at their desk? It seems that it would be a very special situation where an action that is OK for an employee to do while sitting at their desk suddenly becomes a problem when they go home for the night. In that case the admins would also have to disable Cron, At, SSH and any other means of remote access, and then they could enable KillUserProcesses at the same time. > and sometimes employees leave the company. Then their user accounts shall be disabled so that they can no longer log in, and *then* it makes sense to kill all their processes. > 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. I don't see how a spambot is a problem during nights and weekends but not during work hours. A spambot shall be wiped out as soon as it's discovered. It shall definitely not be left in place and allowed to respawn every time the user logs in. Sysadmins can choose to run a cron job that checks for unexpectedly old processes and alerts the admin who then takes a closer look and judges whether the process is legitimate or not. > unless the admin > permitted it explicitly, there should not be user code running. The admin did permit it explicitly when they created the user account. > 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. Then disable the account and run "killall --signal KILL --user intern". > And even more: after you disabled his > user account and logged him out, he really should be gone. After you disabled his user account, he really should be gone. If he's just logged out, he will be back tomorrow. Logging out is one thing. Disabling a user account is another. Kill any lingering processes when disabling the account, not every time the user logs out. A single command that both disables a user account and kills any processes running as that user might be handy. Anyone who thinks it's needed can write such a tool. All of your examples are either very special cases, or else the enforcement belongs in other places than the logout procedure. Thus I'm still not convinced that there is a security problem that affects a typical Fedora system. Björn Persson
Attachment:
pgpWDdYFgaOOf.pgp
Description: OpenPGP digital signatur
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
