On Thu, 2016-06-02 at 13:04 +0200, Lennart Poettering wrote:
On Wed, 01.06.16 07:20, Adam Williamson (adamwill(a)fedoraproject.org)
> On Wed, 2016-06-01 at 15:48 +0200, Lennart Poettering wrote:
> > Any scheme that relies on unprivileged programs "being nice"
> > 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
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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net