Bad file access on the rise

[Lennart Poettering]

On Sun, 09.06.13 11:05, Doug Ledford (dledford at redhat.com) wrote:

> The audit system is just a more modern version of that same thing.  And
> the second you put any sort of exception into the audit rules, then you
> have to verify that the exception can never be used to circumvent the
> legitimate purpose of the rule.  So, if we put an exception into the
> system so that PulseAudio can open these shm files and not be audited,
> we would have to prove conclusively that no other application can ever
> use that exception to hide their tracks (a rather difficult task) or
> risk loosing some of our security certifications.  At least, that's my
> understanding of how these security certifications work, Steve can
> verify this.

You know, audit has so many holes anyway, it's super easy to circumvent
it entirely for any attacker. For example, if I never want to show up in
audit logs about forbidden file accesses I could write a tiny
preloadable library that replaces open()/fopen() by stat() or access()
right before open()/fopen(). Since stat()/access() are generally not
audited this allows me to completely evade any auditing (of course it
would still be ugly and racy as hell, but why would a hacker
care?). That this is possible you are admitting yourself by suggesting
me to do this for the special case of PA. Now, audit of course logs more
than just failed open()s, but I'd be almost willing to bet you that I
can easily find a way to circumvent generation of almost any audit
message in the system.

audit hooks into various subsystems of the OS. It makes assumptions
about why people call certain interfaces, but these assumption are
frequently wrong. And it assumes that people won't hide their intentions
when using these APIs. It assumes bad file accesses were something
unexpected in all cases, and it expects that people which want to steal
all data they can will always try to open the files directly. And in
both cases it is wrong. As the case of PA shows.

Now, this fuzziness of audit doesn't really make it a useless tool, far
from that, but it does make clear that our APIs are not designed with
audit and only audit in mind. Our APIs are usually designed to be
race-free, fast, simple, atomic, secure and a lot of other things in
mind, but auditability is really something that never was on the
table. Because for that they'd have to declare the intention why people
call these functions, and our APIs coud not have been this redundant.

What to make of this? Well, audit has to deal with the fact that its
data is incomplete in some areas, and incldues too much information in
others. Hence its emphasis should be on making the best of its dataset
but not assume too much about it. However, Steve is kinda assuming he
could rearrange his dataset instead. But that's simply not feasible. Not
feasible because of the size of our codebase, not feasible with the
current APIs, and simply because for developers correctness,
race-freeness, simplicity is more important.

> audit subsystem *must* be adding the burden of proving that your fix in
> the audit subsystem can not be abused by malicious hackers to help
> subvert your system (or to hide the evidence of their
> subversion/attempts).  

Ncie idea, but that's precisely the problem. Audit can be circumvented
to easily anyway (see above), this is definitely not something to
check. In our current OS it's the job of the audit guys to make their
reporting tools useful to deal with its incomplete/redundant dataset
rather than the one of the rest of the OS developers to generate audit
data that is perfect in the eyes of the audit guys, at the expense of
code correctness, race-freenes and simplicity.

> > Well, that's clearly not the case in the situation we're actually
> > discussing: the author of one of the pieces of software you audited says
> > he knows about the failed syscalls and does not think they're a problem.
> 
> To answer Steve's question: because the kernel is the ultimate arbiter
> of what's allowed and what isn't, so it's easier and quicker to not
> bother with checking the legitimacy of your options and simply allow the
> kernel to do it for you.  It's lazy, but not wrong.  It is, however,

It's not lazy. It's the only correct thing to do. Reimplementing the
kernel's security checks is nearly impossible. Capabilities, file ACLs,
multiple uids, security frameworks make it incredibly hard to correctly
guess from userspace whether the kernel will grant or deny file
access. And even if you write complex code for this that covers all
current security mechanisms in place, you can bet that this will be
out-of-date in a year or two when the next security technology comes along.

> And really, we've spent more time on this thread than it would take
> Lennart to fix PA.  Just a quick stat and check of uid before trying to
> remove the stale files and this would all go away.  Sure, your stat and
> remove could race, but this is nothing more than a garbage collection
> process anyway, so who cares?  We'll just get it next time.

Yeah, but I don't do hacks like that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.