PolicyKit releases and !AWOL

[David Zeuthen]

On Mon, 2007-12-17 at 04:22 +0100, Michael Biebl wrote:
> > No, but it makes it a lot harder; if you can read the file you can run
> > strings(1) and ldd(1) on it; that alone is a lot of useful information.
> 
> You can do that just as well with the binary that you extracted from
> the deb/rpm.
> So this point is not valid.

It's valid because the attacker might not know exactly what package to
get it from (multiple OS releases; per-site patches etc.). It slows the
would-be attacker down.

> > Sure, it doesn't add security but the program should be secure in the
> > first place (and I believe it is) otherwise it's a stop-ship bug.
> 
> I'm not sure what this has to do with the file permissions.

You implied that I thought making the file non-world-readable was adding
security. I explained to you this wasn't the case; the point is making
it harder if there is a flaw.

> I don't understand what you are trying to say with that. How can a
> flaw in the program be exploited (more easily) if it's world readable?
> Can you give me a real world scenario here? What you say is to vague.

Sure, say that Mallory cracks an unprivileged account on a networked
system (by either technical or social engineering). He now looks through
the system for setuid root binaries. One by one he goes through them
using strings(1), ldd(1) and other tools to find ways to attack it. It's
more work for Mallory if he has to find the exact rpm/deb and analyze it
offline.

> Actually its the other way around.
> Think of backup programs, which now have to run as root to be able to
> successfully create a backup, or intrusion detection systems, which
> check the file checksums, which can't be run unpriviledged.
> I hope I could give you some use cases, why it makes sense to make the
> files world readable.

See that's a much better example

http://gitweb.freedesktop.org/?p=PolicyKit.git;a=commitdiff;h=59081d0a25f6f3227ccba960fa486fd7111baeef

     David