Messages in this thread | | | Date | Wed, 3 Dec 2014 03:23:06 +1100 | Subject | Re: [PATCH 1/2] fs: introduce sendfd() syscall | From | Alex Dubov <> |
| |
On Wed, Dec 3, 2014 at 2:33 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote: >> > User A can send fd(s) to processes belonging to user B, even if user B >> > does (probably) not want this to happen ? >> >> 1. Process A must have sufficient permissions to signal process B. >> This will only happen if process A belongs to the same user as process >> B or has elevated capabilities, which can not appear by themselves >> (and if root on some machine can not be trusted, then all is lost >> anyway). >> > > I do not see this enforced in your patch. > > Allowing a process to hold many times the lock protecting my file > descriptor table is very scary. > > Reserving a slot, then undo this if the signal failed is a nice way to > slow down critical programs and eventually block them from doing > progress when using file descriptors (most system calls afaik)
Yes, this is an omission. I already promised to tighten the security in my last post. :)
>> 2. If process B has not specified explicitly how it wants the >> particular signal to be handled, it will be killed by the default >> handler. End of story, nothing else is going to happen. > > So it seems possible for an arbitrary program to send fds to innocent > programs, that will likely fill their fd table and wont be able to open > a new file. > > This opens interesting security issues and attack vectors.
Same as SIGKILL. And yet, our machines are still working fine.
If process A has sufficient capability to send signals to process B, then process B is already at its mercy, fds or not fds.
| |