On Fri, 07.06.13 12:09, Steve Grubb (sgrubb(a)redhat.com) wrote:
> > > POSIX shared memory doesn't define any useful
scheme for automatic
> > > removing of shared memory segments from /dev/shm after use. Hence, in
> > > order to make sure that left-over segments don't fill up /dev/shm
> > > forever PA will try to GC dead segments from /dev/shm on each
> > > start-up. For that it iterates through /dev/shm/pulse-shm*, tries to
> > > read the PID that is stored in there.
> >
> > Maybe the uid can be encoded in the name so that wrong uid's are
> > skipped?
>
> But why?
So that you are not filling up the audit logs. There are people that have to
use these audit rules and we need a normally operating system to produce as
few false positives as possible.
Maybe the audit system should be fixed to not trip up by this?
> This stuff should be simple, and it's always a better idea
to
> simply let the kernel do EACCES rather then trying to be smarter than
> the kernel and reimplement access control in userspace.
Well, you are already trusting the name. Who's to say some rougue process
didn't create the file name to try and trick pulseaudio?
Well, if the process did that, then we'd just delete his shared memory
block. I don't feel particularly tricked there... ;-) And besides that,
note that PA also checks a file signature before deleting the file, just
to be sure to not delete anything of importance...
How about doing like some processes do in the /tmp dir...put the
segments in a directory /dev/shm/<user name>/ and then scan all the
files that belong to that user?
Guessable directory names in a world-writable directory? I am sorry,
that's not an option. The stuff is already DoS-able enough, I am pretty
sure I don't want to open the door even wider. (Also what is this,
anyway? of all people, you as a security guy should know what bad an
idea that is...)
There are ways to make this better if you are willing. :-)
Well, or you could make audit better, if you are willing.
Lennart
--
Lennart Poettering - Red Hat, Inc.