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

[Mike Hearn <mike navi cx>]

On Fri, 14 Jan 2005 10:18:18 -0500, Sean Middleditch wrote:
>> 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.
> 
> This is wrong.  The problem is that you are assuming all users are
> ignorant and thus punishing the ones that aren't.  If all users are
> effectively running as UID 0 then any malware that gets installed (say,
> by a child grabbing something off the net, or a bug in your browser that
> allows code injection) also has UID 0.

Yes UID 0, if they are running as a totally new process or whatever. So
yes they could do whatever the user could do, install new software, touch
others files etc.

How does this happen? If bad software gets on your system and the user has
told the computer to run it then we already lost. Bugs in browsers happen:
we have SELinux to give damage control, and funky patches like execshield
and ProPolice to try and stop it happening. Children installing malware
happens, but I already talked about fighting malware in another mail. 

If it's just general distrust of children then you're presumably wanting to
configure exactly what they can and cannot do at a fine level of control
which makes you a sysadmin who wants MAC :) 

But yes there could definitely be a nice SELinux GUI or whatever that lets
you say "confine user XYZ to their home directory" if you want to let
them play in a sandbox.

> If you separate the privileges and require that gaining the "install
> software" privileges requires that the code path go through a particular
> utility, like a single software installer, you can put checks in one
> place and know they can't be circumvented.  For example, sure a malware
> could craft an RPM on the fly but can it sign it with a key you trust?

Well this is heading in the right direction of removing authentication
for home users with locked down software, but ....

I've never, ever seen a desktop operating system that managed to actually
succeed with a single software installer. RiscOS got the closest but it
was a much simpler system. MacOS hasn't, Windows never even tried, despite
best efforts Linux failed miserably at this too. So any security system
that relies on only one program being able to install software just isn't
going to work.

Installing stuff is just another way of reconfiguring the system anyway,
for software that happens to need it. If the user is in control (because
it's a private system that they own) they should be able to configure it
in any way they see fit. Not all software needs to be installed.

> And yes, there is a distinct difference between installing stuff in /usr
> and installing it in $HOME in the event that you have several accounts.
> If my girlfriend somehow gets a trojan installed into her account it
> will only affect her account and not my files - imagine if my
> (relatively) computer-inexperienced girlfriend's actions could infect
> the source code repositories I have access to from my account!

OK, I still think the default should be shared as I think most users do
not have security-sensitive information or data in their $HOME :) But OK
there should be some simple way of using ACLs from Nautilus (in such a
setup).

> Slightly off-topic, but my only "fear" with replacing DAC with MAC is
> that the current MAC-for-Linux system around that's got any traction is
> SELinux, and even the SELinux gurus seem to have trouble getting a
> general-use working system locked down effectively with it.  It's too
> complicated to configure and use.

Yes, this worries me too. I don't know if SELinux is badly designed or if
MAC in general is just a very hard problem, or even if Red Hat are being
overly ambitious. I'm not aware of any attempts to do something like this
before.

> This could be "fixed" by simply changing the warnings to errors - if a
> remote site doesn't have a valid certificate then don't give the user an
> "ignore" option.  This of course must be accompanied with an easy way
> for admins to install system-wide certificates (instead of having to
> install it in each individual application) and of course an easier way
> to get authenticatable certificates.  (cacert.org looks like a good
> start, although they have a long way to go to work the bugs out of the
> management and get things settled and working smoothly.)

Yeah that'd be one way to start fixing the SSL mess but there are big
limits to what you can do given IEs dominance. So I think for now we
should just learn from its mistakes and leave it for broke ....
 
> Basically, be pro-active about security.  When your choices are a) make
> it simple for the user or b) make sure their credit card isn't stolen,
> you really need to go for b.  Easy is worthless if all you can do is
> easily get screwed.  Computers exist to help people, not fool people
> into thinking they're being helped.  Remember, we're talking about "Ease
> of use" and not "ease of misuse."

The flip side is that somebody, somewhere will always offer an easy way
out. I tend to agree with Havoc that manual security is no security at all
because once it becomes too invasive or difficult users will just switch
it off. If there's no way to switch it off, they'll use something else to
get their work done.

A really secure but unusable box is just a paperweight .... but this is
the tradeoff software designers have been making since the beginning of
time :)