Bad file access on the rise

Simo Sorce simo at redhat.com
Fri Jun 7 16:42:49 UTC 2013


On Fri, 2013-06-07 at 18:21 +0200, 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? 

Lennart,
it's fun to troll, but seriously, the audit system *audits*, it's not
hard to understand.

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

Sorry but what makes /dev/shm/pulse-shm-3756395503 more/less guessable
than /dev/shm/<uidnumber>/pulse-shm-3756395503 ?

> > There are ways to make this better if you are willing.  :-)
> 
> Well, or you could make audit better, if you are willing.

Or you could actually listen.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list