[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: |
Mon, 28 Sep 2015 21:19:14 -0400 |
User-agent: |
KMail/4.14.10 (Linux/4.1.5-gentoo; KDE/4.14.12; x86_64; ; ) |
On Monday, September 28, 2015 05:34:53 PM Namsun Ch'o wrote:
> > To be clear, I'm not suggesting "--enable-syscalls=foo,bar,...", what I'm
> > suggesting is a decomposition of the current filter list into blocks of
> > syscalls that are needed to enable specific functionality. For example,
> > if you enable audio support at runtime a set of syscalls will be added to
> > the filter whitelist, if you enable a network device a different set of
> > syscalls will be added to the filter, and so on.
> >
> > I think having an admin specified filter, either via a command line or
> > configuration file, is a step in the wrong direction.
>
> How come? I think it is safer than forcing an admin to re-compile everything
> (which just won't happen in an enterprise environment).
For starters, I don't believe that a random administrator understands the QEMU
code and the potential impact of any changes to such a config file as well as
the QEMU developers.
> ... If any configuration file only increases the strictness of a syscall, I
> don't see the danger of an admin shooting themselves in the foot. Allowing
> an admin to decrease security would be a problem, but they can do -sandbox
> off anyway.
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.
Also, while yes, allowing an admin to disable the sandbox via a command line
switch does disable the seccomp filter, it is obvious that such a step is
being taken.
> But if the dynamic sandbox is strict enough for each feature, it'd be great.
--
paul moore
security @ redhat