On Fri, 07.06.13 12:09, Steve Grubb (sgrubb@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
