On Sun, 09.06.13 11:05, Doug Ledford (dledf...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
