[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox
From: |
Paul Moore |
Subject: |
Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox |
Date: |
Tue, 29 Sep 2015 18:12:17 -0400 |
User-agent: |
KMail/4.14.10 (Linux/4.1.5-gentoo; KDE/4.14.12; x86_64; ; ) |
On Monday, September 28, 2015 11:14:42 PM Namsun Ch'o wrote:
> > My understanding of the config file you proposed is that it would allow
> > the
> > configuration of a whitelist, so changes to the config very could result
> > in
> > *less* strict of a filter, not always more.
>
> No. Any time an administrator wants a syscall that is not enabled in the
> sandbox, they either don't actually need it, or it's a bug and should be
> fixed. So all the config would do is add argument filters to syscalls which
> are already whitelisted.
If the syscall, without arguments, is already added to the whitelist then
adding a new libseccomp rule to allow that same syscall with specific
arguments will have no effect since a broader rule already exists in the
filter.
> The alternative would be that the syscalls are given no further argument
> filtering. The config could only make the filteres more restrictive, never
> less.
I still don't see how this is the case, but it probably isn't worth arguing
any further without some patches.
> Perhaps there could be a #define somewhere that toggles whether or not a
> syscall argument filter can be created for a syscall which is not in the
> built-in whitelist, otherwise it would throw an error saying that you cannot
> create an argument filter for a syscall that is not permitted.
I would argue you should never be able to add a syscall to the whitelist via a
config file and/or command line option, but that is my opinion.
--
paul moore
security @ redhat