From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgwyr-00075x-IN for qemu-devel@nongnu.org; Tue, 29 Sep 2015 11:38:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgwyo-0003OA-Pw for qemu-devel@nongnu.org; Tue, 29 Sep 2015 11:38:13 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:33050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgwyo-0003Nm-K0 for qemu-devel@nongnu.org; Tue, 29 Sep 2015 11:38:10 -0400 Received: by wiclk2 with SMTP id lk2so157287065wic.0 for ; Tue, 29 Sep 2015 08:38:10 -0700 (PDT) Date: Tue, 29 Sep 2015 17:38:07 +0200 From: Eduardo Otubo Message-ID: <20150929153807.GB10053@vader> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Namsun Ch'o Cc: pmoore@redhat.com, qemu-devel@nongnu.org --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (I'm not sure what happens to your emails that all of them does not relate to the same thread/Message-ID, making a pain to follow through out the volume of email on the list, please pay attention to that) On Mon, Sep 28, 2015 at 11=3D14=3D42PM -0400, 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 resul= t in > > *less* strict of a filter, not always more. >=20 > 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 whi= ch > are already whitelisted. The alternative would be that the syscalls are g= iven > no further argument filtering. The config could only make the filteres mo= re > restrictive, never less. By its concept, adding exception to the whitelist always makes it less restrictive by definition, but I got your point. Another point here, though, is that whitelisting syscall is not as common as you think it is. I've been maintaining this sub-system for more than an year now and I had to review/commit/push very few times. Seccomp sandboxing is enabled by default on virt-test, so whoever is using that framework is also testing their workload against the current syscall whitelist. If no one has hit any problem so far, it means the whitelist is in good shape for usual workloads and configurations. I'm not particularly against any improvement like configuration files or more command line args, but I'm concerned about the security itself. If some guest can scape to the host, it's gonna be much easier to whitelist syscalls for the next guests, changing the command line is a little too obvious -- paranoid example, I know. If you want to write an RFC with your idea, you're more than welcome. We could move on this discussion and perhaps come up with a nice solution. Regards, >=20 > 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 can= not > create an argument filter for a syscall that is not permitted. --=20 Eduardo Otubo ProfitBricks GmbH --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWCrBfAAoJEP0M/1sS+L0vAZwIAJownws4pcYwlSnv7q+2aZQ/ LXYhiYRODkJCeesY+DcPegu01DwP96NLtlsKhKXoII7qEHeLnB/mYuf7SQlRN1Rl qDJ7BlmIZiUII3OLg5K6ZZezktgMXxfubawegKwvf5aXOz5h3mV6tBKEVPpxmPzz i6xoD6z8UTtKsHRbP2m0Czif8NN8qG3ehVyat/ybWkYgzCANHX/5Vf6ZglopvBfU JRgVjRC/p1UdAGUHUpZHr2u5GnbnQJO3w9wYAEi0nYBF9GKYWLMLmTJU2ed8w3OF LJSQkb37C6R7QWE3NTVZRbBuyB26TgRB09etx2uEHTqhBaClQFkZWifcq03ysXY= =rlpi -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU--