All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org, pmoore@redhat.com
Subject: Re: [Qemu-devel] RFC: How to make seccomp reliable and useful ?
Date: Thu, 2 Mar 2017 09:35:26 +0000	[thread overview]
Message-ID: <20170302093526.GB29835@redhat.com> (raw)
In-Reply-To: <20170301223856.GA20202@vader>

On Wed, Mar 01, 2017 at 11:38:56PM +0100, Eduardo Otubo wrote:
> On Thu, Feb 16, 2017 at 09=33=16AM +0000, Daniel P. Berrange wrote:
> > On Thu, Feb 16, 2017 at 12:36:51AM +0100, Eduardo Otubo wrote:
> > > On Wed, Feb 15, 2017 at 06=27=32PM +0000, Daniel P. Berrange wrote:
> 
> [...]
> 
> > > > 
> > > > There is a reasonable easily identifiable set of syscalls that QEMU should
> > > > never be permitted to use, no matter what configuration it is in, what helpers
> > > > it spawns, or what libraries it links to. eg reboot, swapon, swapoff,  syslog,
> > > > mount, unmount, kexec_*, etc - any syscall that affects global system state,
> > > > rather than process local state should be forbidden.
> > > > 
> > > > There are some syscalls that are simply hardcoded to return ENOSYS which can
> > > > be trivially blacklisted. afs_syscall, break, fattach, ftime, etc (see the
> > > > man page 'unimplemented(2)').
> 
> I've been working on the blacklist, you can see here:
> https://github.com/otubo/qemu/commit/31e603180081474ff35c5897813cb635f8e9a786
> 
> I didn't send as an RFC to the list because it's still an on going work,
> but if you have any comments, please feel free.
> 
> > > > 
> > > > There are some syscalls which are considered obsolete - they were previously
> > > > useful, but no modern code would call them, as they have been superceeded.
> > > > For example, readdir replaced by getdents. We could blacklist these by default
> > > > but provide a way to allow use of obsolete syscalls if running on older systems.
> > > > e.g. '-sandbox on,obsolete=allow'. They might be obsolete enough that we decide
> > > > to just block them permanently with no opt in - would need to analyse when
> > > > their replacements appeared in widespread use.
> 
> The obsolete part is also on my github (didn't send for the same
> reason):
> https://github.com/otubo/qemu/commit/54a57eb150ca3e5b67e9a81394c6cfa4ac82a6ff
> 
> Also, can't find anywhere a solid list of obsolete system calls, can you
> elaborate a little more on how to determine this list?

Systemd has such a list in ./src/shared/seccomp-util.c
Look for the array containing SYSCALL_FILTER_SET_OBSOLETE


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  reply	other threads:[~2017-03-02  9:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 18:27 [Qemu-devel] RFC: How to make seccomp reliable and useful ? Daniel P. Berrange
2017-02-15 23:36 ` Eduardo Otubo
2017-02-16  9:33   ` Daniel P. Berrange
2017-03-01 22:38     ` Eduardo Otubo
2017-03-02  9:35       ` Daniel P. Berrange [this message]
2017-02-16  8:38 ` Thomas Huth
2017-02-16  9:32   ` Daniel P. Berrange
2017-02-16  9:37     ` Thomas Huth
2017-02-16  9:41       ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170302093526.GB29835@redhat.com \
    --to=berrange@redhat.com \
    --cc=pmoore@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.