Least privileges [was: Re: Fedora power management]

[David Zeuthen]

On Fri, 2004-11-19 at 10:18 +0100, Martin Pitt wrote:
> Hi David!
> 
> David Zeuthen [2004-11-16 17:08 -0500]:
> > I kind of think saying "no callouts" and "run unprivileged" is just not
> > the right solution - it sounds to me like a copout. 
> 
> That's not quite what Sjoerd and I propose - if somebody wants to use
> callouts, he should be able to. Our proposal was to run hal itself
> with the least possible privileges, that is, as normal user.
> 
> Hal already had a lot of buffer overflows and unchecked inputs and
> looking at the code show that there are many, many more.

True, but all that input is from a trusted source, e.g. the kernel, so
what is your point? The only place we read untrusted data is volume_id.

You may want to remember that the system message bus does a lot of
checking and throttling control to weed out attackers.

>   But it
> currently runs very fine as normal user (so we can neglect the impact
> of security holes), so it is really a great thing to have. I just
> don't see why I should take the risk of running it as root just for
> the sake of it.  The credo of security is "least privilege" and we
> should aim to reach it (we are already very close to it currently).
> 

No disagreement here obviously; see my mail on my proposed split.

> > Distributors deploying hal do need callouts and will need the
> > methods.d stuff to (auto)-configure the hardware.
> 
> Nobody asks you to remove that feature. It is still present in Debian
> and Ubuntu can can be used at will.
> 
> > The alternative is having setuid root binaries (e.g. like pmount) for
> > everything to enforce policy; I'm not sure that is a good idea, compared
> > to D-BUS methods, for, well, a multitude of reasons.
> 
> Why? Instead of neglecting the problem and having _everything_ run as
> root, every callout and and other client can individually gain as much
> privileges as it really needs. You exchange a daemon with lots of
> communication (input validation!) that permanently runs as root with
> some minimally privileged clients which run only a short time and have
> relatively little input to check. How can this be a bad thing?
>
> E. g. pmount does most of its job as normal user and only switches to
> root for function calls that really need them. A printer configuration
> backend could be setgid lpadmin instead of setuid root (works very
> well with CUPS, e. g. Ubuntu's CUPS does not run as root as well). A
> network configuration callout needs to be suid root and immediately
> drop everything but CAP_NET_ADMIN.
> 
> Please don't encourage laziness on the side of the authors of
> callouts. People should be aware of the privileges of their scripts
> and their possible security implications.
> 

Hey, the callouts can drop privileges instead of being a setuid binary
if you are concerned about that. 

Making them setuid root is a bad idea - remember, every joe random user
who got an account on some home system can exec a suid binary; one that
you only want haldaemon to execute, e.g. as a callout.

Btw, can any joe random user that logs into a Ubuntu system use pmount
to gain access to filesystems from, say, a USB2 hard drive? He shouldn't
really, in my view. I understand that it may be a desirable thing
though, we just don't allow that in Fedora because of security concerns.

(note: I'm not trolling, see below)

My point is really that all such policy and privilege checking can be
done in a single location instead of in each setuid binary; namely hal
or D-BUS. Sure, we need to make an option called --use-pam-console for
hald to respect to determine if this or that method is allowed to be
invoked by the user [1].

[1] : Btw, it would be really nice with a standard distro independent
way of determining if a user should be e.g. allowed to mount a file
system; rename a disk label, shut down the computer etc. Is PAM being
used in e.g. Debian or Ubuntu. What does SUSE do?

> > (and anyway, with SELinux, the concept of root is sort of going away -
> > the hald process just need to be allowed to do certain things).
> 
> This is exactly what we already did - give hald the privileges it
> needs. There is no need to wait for a MAC system to be supported by
> default (or to be maintained by the user). SELinux is a great thing,
> but MAC systems are very difficult to handle on Desktop systems and it
> will take many more years until they become standard. And then you
> will have the same problem again -- you have to explicitly specify
> privileges of callouts and clients.
> 
> In Ubuntu and Debian you have a working solution now - just an apt-get
> install away. And I am really grateful that you accepted the privilege
> dropping into your official version, too. Thanks again for this, it
> eases a distributor's job a lot.
> 

I am happy to hear your input now and in the future.

> > What could be far more interesting to discuss is how to decouple
> > this callout/methods.d stuff from the main hald process in a
> > sensible way so not all the code run as root. 
> 
> I do not see the problem here. No code of hal whatsoever needs to
> run as root, so this already seems to be solved.
> 
> > I personally think the right solution here is to make hald fork()
> > into two processes and make one of them drop privileges and just
> > listen for hotplug events and monitor stuff (what hald does today
> > except the callouts, only with dropping privileges). The other one
> > could do callouts and methods.d stuff. The IPC used could be really
> > simple or it could be D-BUS in peer to peer mode.
> 
> If you really want to provide such a split, I would propose to do it
> the other way round: take hal as it is, have it run as normal user and
> only separate out the part that calls scripts (and let it run as
> root). The two instances would communicate over D-BUS (I suppose) and
> the callout "stub" would be very small and easy to audit.
> 
> However, I do not really see what the benefit would be compared to
> having optionally setuid/setgid callout scripts. Currently we do not
> need to become root ever for most use cases and can place a setuid
> callout when we need it. And having a daemon which executes things as
> root on D-BUS request introduces the potential security hole again. 
> 
> Thanks for considering and have a nice day!
> 

See my mail to Sjoerd.

Have a good one

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal