On Fri, Jun 7, 2013 at 6:55 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > Well, you know, this problem isn't new. Some SELinux AVCs can be set to > ignored for precisely reasons like this one, because it is common that > things like these happen: accesses which fail where that is > expected. Well, whether it _should be_ expected that accesses fail is the primary question here. UNIX has somewhat a tradition of relying on syscall error codes to avoid one more user/kernel round trip (see e.g. the "News Need Not Be Slow"), but it's not obvious that this is the right thing to do at all, especially in non-performance-critical code. SELinux as a primarily access control mechanism does not have perfect audit information _by default_, but for those who want the full audit information, it is still available: http://danwalsh.livejournal.com/11673.html ). Similarly, audit doesn't log anything of this _by default_, but it is available - and required, as Stephen has explained. Pragmatically speaking, SELinux also has far more information, that allows it to write reasonably dontaudit rules. For example, > dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind; can be most likely traced to a single line of code and a single executable. What _would_ the audit change that made an exception for PulseAudio look like? I haven't looked at the code, but from this thread it seems it would have to be "any application running in an user session (or perhaps even outside of it) can try to open any shared memory segment". That's far too broad and not acceptable. AFAICS this can be solved by a ~100-line? patch to the pulseaudio ecosystem, or by doing much more work and coordicnation to design a different shm mechanism or a new shm namespace. I'm not planning to work on it so I suppose my opinion has little weight, but this doesn't seem like a difficult decision at all. Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
