Bad file access on the rise

[Miloslav Trmač]

On Fri, Jun 7, 2013 at 6:55 PM, Lennart Poettering <mzerqung at 0pointer.de> 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