linux-kernel - Re: syscall: introduce sendfd() syscall (v.2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPs88r-CH+x3srCCcoXdBvno3t1mN__TgaTKRKPR43_u1_5+fg@mail.gmail.com>
Date:	Sat, 6 Dec 2014 15:13:48 +1100
From:	Alex Dubov <alex.dubov@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Jonathan Corbet <corbet@....net>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: syscall: introduce sendfd() syscall (v.2)

On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
>
>> 2.a. If task A has sufficient capabilities to send signals to task B, then
>> task A is already in position to do anything it wants with task B, including
>> killing it outright.
>
> Not entirely true.
>
> - We have securirty models like SELinux
> - We have namespaces and being able to send an fd between namespaces is
>   not quite as flexible as you would make it
>
> I suspect therefore it needs security hooks but otherwise looks more sane
> than the current AF_UNIX approach.
>

The best part about signal transport compared to anything in net/ is
that it adheres to very straightforward and simple API contract. That
is, you can tweak it here and there and still keep everything working.

1. adding an additional capability flag to selinux does not appear to
be that complicated (it's got 4 capabilities related to signal
handling already, fifth is not going to make much difference)

2. sending fds between namespaces may be prohibited outright; this
would not be an unreasonable prohibition. A more flexible model may
also be feasible, but I wonder if necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/