Bad file access on the rise

[Steve Grubb]

On Friday, June 07, 2013 06:21:00 PM Lennart Poettering wrote:
> On Fri, 07.06.13 12:09, Steve Grubb (sgrubb at 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?

As I said before, this rule comes from the DISA STIG. Its not an audit bug, 
its doing exactly what its supposed to do. Its seeing questionable behavior 
and logging it.

 
> > > 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...

OK, good. Then we can agree that it only deletes files that look like they 
belong to pulse audio and because of the sticky bit on /dev/shm, only files you 
own can be deleted.

> > 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...)

The idea is not bad. Its the implementation that can be bad. Its possible to 
do this safely. And if you don't like this, then there are other ways to do 
it. You can add the user name to the file name and because we established above 
that pulseaudio won't delete the wrong kind of file, you are now able to 
determine which one to open. A benefit to doing this is that your code should 
be faster because strncmp() on the name and skipping the file is faster than 
doing a syscall which in turn does name resolution and then determines access 
permissions. Faster is good, right?  :-)

It might also be possible to unlink the file soon after creating it so that 
when the last reference is closed the file goes away automatically.

-Steve