Re: More desktop security thoughts (was Re: GNOME privilege library)

[Havoc Pennington <hp redhat com>]

Hi,

I don't think it's that complicated. Generally speaking just getting the
"what normal users are allowed to do" line right solves the problem.

The line is then modifiable by a site admin (or tech-savvy user), just
like any other setting. Simple.

The only time end users need the root password is when we have a
technology bug that makes capabilities insufficiently fine-grained to
properly say "users can do X, but not Y"

Think about it: why should anyone need two passwords? The system should
know what each user is allowed to do based on the user's role. The user
shouldn't have to explicitly change "who they are," that's just
annoying.

SELinux or consolehelper or whatever add more layers, i.e. we can have a
capability which is granted only in particular contexts (running certain
apps, editing certain files, at console). Finer-grained control means
you can give people only the most specific possible capability and thus
avoid some of the virus/spyware type problems.

So anytime you have to auth as root it's pretty much a bug as far as I'm
concerned. But just setting all uids to 0 is equally dumb because it
gives you a lot of capabilities you don't need which leads to broken
systems and malware.

Most Linux desktop deployments today use sudo/pam to do exactly what I'm
saying here; or else they just give people the root password. I think
the "grant capabilities" approach is both more secure and more usable
than giving people root or logging in as root.


What about home desktop? Point one is that it isn't that different from
a managed desktop. Office workers with sysadmins still need to be able
to do a lot of things that traditionally require root on Linux:
configure displays, plug in hardware devices, etc.

But, I'll talk about home for a minute. First, let's a priori specify
that we only care about GUI-only users for this discussion, as most
desktop users will be. The reason we don't care about the command line
is that having to know and type the root password is not a problem for
people who use the command line, so we have no problem to solve.

The hardest problem unique to home vs. office is that home users need
capabilities to install software. I would argue that the user account
should simply have the ability to run the software installer program
(some part of which would run as root behind the scenes).

To solve viruses, the right approach is to limit that installer program
somehow (enforce signatures? only allow GUI usage, no scripting?)
Limiting it via root password is imaginary security, since the root
password can trivially be obtained from any naive user by a malicious
app. Plus they probably set the root password to their first name or
something.

For modifications of system files other than installing software, we
know that either 1) they know how to use the shell and can su root or 2)
they are using one of a predetermined set of apps. So in case 2), we
simply allow those apps to change exactly what they should be allowed to
change. (Or in the stateless Linux model, avoid system files that need
mods entirely.)

99% of the time, security that involves asking the desktop user a
question is trivially breakable security. Whether it's certificate-
related dialog spam in web browsers or asking for the root password or
non-automatic Windows updates. The state of Windows desktop security
today is pretty convincing empirical evidence of this.

The world is gradually catching on. Windows XP SP2 updates your system
without asking (you can override it, but just as most people didn't stay
updated when that was the default, most people *will* stay updated when
security is the default). There's work on hardware token based "just
works" crypto to replace the SSL-dialogs-nobody-understands + bad
passwords disaster that is web security today. etc.

Automatic security is the only security. Manual, user-pestering security
is just engineers appeasing their own conscience without solving the
problem. It's the "PEBKAC" answer to security. "Well, it *can* be used
securely." The question should be, "*will* it be used securely and if
not, what work do we have to do so it will be."

</rant>

Havoc