coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Seccomp in coreutils


From: Pádraig Brady
Subject: Re: Seccomp in coreutils
Date: Sun, 21 Jan 2018 18:42:20 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 21/01/18 11:57, David Sastre wrote:
> Hello,
> 
> I have been recently playing around with seccomp and the coreutils source
> code and was wondering about the feasibility of implementing seccomp
> filters in the tools.
> The main benefit for the project would be offering the possibility of
> reducing exploitability by reducing the system calls a program might make,
> using a whitelist.
> Searching the mail archives of the project for discussions around this
> topic has not been fruitful, hence my asking.
> 
> I have tested locally with some of the easiest examples possible (true and
> echo) and a, quite possibly, very naive implementation; but it seems to
> work as expected.
> If I where to put some effort in this, and provided this functionality is
> made explicitly GNU/Linux dependant and optional, would there be interest
> from the group? I would most probably require assistance with the autotools
> changes required, not to mention code review.
> My main inspiration for this request is the OpenBSD pledge()[1] syscall,
> which is applied to the base system (containing most of the equivalent
> tools in GNU/Linux land). You can check an example[2] on the 'echo' tool
> source code.
> 
> Regards and thanks in advance for any feedback, I would love to hear from
> the devs even in the case this request is considered not useful.
> 
> [1] https://man.openbsd.org/pledge.2
> [2] https://github.com/openbsd/src/blob/master/bin/echo/echo.c

Hi,

I'm not convinced of the generality of using seccomp in all utils,
because if it's optionally enabled then one have similar restrictions
using selinux or apparmor etc. (which can also be optionally disabled).
Also this would be adding options for linux specific functionality.
The main use case for seccomp I think is for linux specific "container" tools.
Especially for always installed tools like coreutils, system level
restrictions using selinux or apparmor etc. seem to be more appropriate?

BTW for some seccomp related plumbing in coreutils see this (revert) patch:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=8cb06d4

thanks for the proposal,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]