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

[Mike Hearn <mike navi cx>]

On Thu, 13 Jan 2005 20:31:50 -0500, Havoc Pennington wrote:
> 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.

Right, it's not all that complicated. My main point is that in a home
setup, "normal users" are often on their own and they shouldn't have to
know a root password in addition to their personal one. But unless you
relax UNIX security almost entirely at some point that *will* happen, and
at that point as you never told the user what the root password is they're
stuck.

So I don't see any scalable way to get this right without pretty much
disabling DAC security.

> 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.

Right, and hard to explain and insecure etc etc

> 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.

Are you sure they're not needed? Eg being able to install software
basically implies being able to arbitrarily modify nearly any system
setting. Oh sure you can say "only RPM can install software", but 3rd
party ISVs like game developers will still produce Loki Setups and the
like so you'll end up with software dumped in $HOME. And it's not any more
secure against malware because it's trivial to synthesise RPMs at runtime
then "install" them to get any effect you like. In other words, you might
as well just let any user scribble over /usr at will.

Here's another example: Linux only lets root processes raise their thread
priorities. That makes sense on a server but it's an appcompat problem on
the desktop because Win32 apps sometimes assume they can do this and break
in subtle ways if they can't. So now Lucy has to run Dungeon Siege via
sudo or whatever.

How many other examples are there of random stuff like beeping the
speaker which need root today? I don't know. But probably lots. 

Relaxing DAC security and effectively replacing it with MAC may sound
scary and broken, but that's just because we're all coming from a UNIX
background. We're so ingrained in the idea that *users* shouldn't have
certain privileges that anything else seems weird. The end result should
in theory be more secure than before, because instead of relying on not
running as root app authors can actually assign their program only the
privs it needs.

> To solve viruses, the right approach is to limit that installer program
> somehow (enforce signatures? only allow GUI usage, no scripting?)

So, I think there are two types of program we want to protect against:

(1) Viruses/worms which spread automatically by exploiting flaws in the 
    system construction (buffer overflows etc)

(2) Spyware/trojans/BackOrifice/Phatbot-style apps and so on which
    generally spread manually via social engineering

Some use both.

Solving two is really hard, and boils down to providing the user with
enough information to make a good decisions. That was the theory behind
SSL security - it's automatic but if the math doesn't work out give the
user a big warning explaining what's wrong. Effectively it was a
distributed whitelist for secure websites.

And for a few years it worked quite well. The big mistake SSL made was
that getting onto that whitelist was far too hard. The big CAs (a) charged
lots of money and (b) were generally Evil anyway. So now most secure
websites I visit show me this dumb warning because Red Hat or navi or
whatever just generated an Apache snakeoil cert. It's not so bad for
regular users as most e-commerce sites still suck it up and get a regular
certificate, but SSL warning fatigue definitely got worse lately.

The other problem is the warnings were too complicated. But
that's a failing of browser usability which we understand a lot better
these days.

So I think one good way to tackle the problems of malware/spyware is
to have a similar kind of distributed whitelist but for software. Key
points to avoid the mistakes of SSL would be:

- Very very easy to get on. No need for paperwork or to prove your
  identity. This isn't about auditing code to make sure it's trustworthy,
  that's impossible anyway, it's simply another form of damage control.

- Very easy to get kicked off if there's evidence of wrongdoing.

The point is to minimize false positives so the user actually pays
attention when the computer cries wolf.

It's hardly a full solution but it'd be a start.

That leaves viruses and worms. These are much easier as they (for
the purposes of this classification) spread by exploiting regular security
bugs. SELinux, execshield, firewalls, GCC4 stack canaries etc all help
improve this situation. DAC security does a little bit but it's really not
very useful for protecting against viruses as you don't need root to
initiate network connections to others, or to scribble over $HOME, or
access your email address book or any of the other things viruses do.

Basically I don't think viruses+malware is an argument for DAC security.

> 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.

Right :)

> 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.)

Yep, letting programs specifically change only a bit of configuration is
what SELinux lets us do (whereas the current model is have a daemon which
runs as root and very carefully exposes a limited safe-for-scripting
interface).

> [snip rest of nod-head-this-makes-sense email]

thanks -mike