From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [RFC PATCH 2/2] tun: fix LSM/SELinux labeling of tun/tap devices Date: Wed, 05 Dec 2012 22:01:31 +0800 Message-ID: <2433879.zRVUYBGg1f@jason-thinkpad-t430s> References: <20121129215724.30020.69464.stgit@sifl> <50BEE76A.3080707@redhat.com> <20121205114455.GB26649@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Paul Moore , netdev@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36381 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751676Ab2LEOBt (ORCPT ); Wed, 5 Dec 2012 09:01:49 -0500 In-Reply-To: <20121205114455.GB26649@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wednesday, December 05, 2012 01:44:55 PM Michael S. Tsirkin wrote: > On Wed, Dec 05, 2012 at 02:19:22PM +0800, Jason Wang wrote: > > On 12/05/2012 02:17 AM, Paul Moore wrote: > > > On Tuesday, December 04, 2012 07:36:26 PM Michael S. Tsirkin wrote: > > >> On Tue, Dec 04, 2012 at 11:18:57AM -0500, Paul Moore wrote: > > >>> Okay, based on your explanation of TUNSETQUEUE, the steps below are > > >>> what I > > >>> believe we need to do ... if you disagree speak up quickly please. > > >>> > > >>> A. TUNSETIFF (new, non-persistent device) > > >>> > > >>> [Allocate and initialize the tun_struct LSM state based on the calling > > >>> process, use this state to label the TUN socket.] > > >>> > > >>> 1. Call security_tun_dev_create() which authorizes the action. > > >>> 2. Call security_tun_dev_alloc_security() which allocates the > > >>> tun_struct > > >>> LSM blob and SELinux sets some internal blob state to record the label > > >>> of > > >>> the calling process. > > >>> 3. Call security_tun_dev_attach() which sets the label of the TUN > > >>> socket > > >>> to match the label stored in the tun_struct LSM blob during A2. No > > >>> authorization is done at this point since the socket is new/unlabeled. > > >>> > > >>> B. TUNSETIFF (existing, persistent device) > > >>> > > >>> [Relabel the existing tun_struct LSM state based on the calling > > >>> process, > > >>> use this state to label the TUN socket.] > > >>> > > >>> 1. Attempt to relabel/reset the tun_struct LSM blob from the currently > > >>> stored value, set during A2, to the label of the current calling > > >>> process. > > >>> *** THIS IS NOT CURRENTLY DONE IN THE RFC PATCH *** > > >>> 2. Call security_tun_dev_attach() which sets the label of the TUN > > >>> socket > > >>> to match the label stored in the tun_struct LSM blob during B1. No > > >>> authorization is done at this point since the socket is new/unlabeled. > > >>> > > >>> C. TUNSETQUEUE > > >>> > > >>> [Use the existing tun_struct LSM state to label the new TUN socket.] > > >>> > > >>> 1. Call security_tun_dev_attach() which sets the label of the TUN > > >>> socket > > >>> to match the label stored in the tun_struct LSM blob set during either > > >>> A2 > > >>> or B1. No authorization is done at this point since the socket is > > >>> new/unlabeled. > > >> > > >> Here's what bothers me. libvirt currently opens tun and passes > > >> fd to qemu. What would prevent qemu from attaching fd using TUNSETQUEUE > > >> to another device it does not own? > > > > > > True, assuming all the above is correct and that I'm understanding it > > > correctly (Jason?), we should probably add a new SELinux access control > > > for > > > TUNSETQUEUE. > > > > Yes, we need make sure qemu can call TUNSETQUEUE for the device it does > > not own. > > Meaning can *not* call? Sorry for not being clear, I mean qemu can call TUNSETQUEUE for the device it owns and for the device it does not own, it can't call. > > > > The current DAC code exists in tun_not_capable().