From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id qB6Gvf3p022401 for ; Thu, 6 Dec 2012 11:57:41 -0500 From: Paul Moore To: "Michael S. Tsirkin" Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, jasowang@redhat.com Subject: Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices Date: Thu, 06 Dec 2012 11:56:45 -0500 Message-ID: <6001427.qD54i2BbtH@sifl> In-Reply-To: <20121206161200.GA4340@redhat.com> References: <20121205202144.18626.61966.stgit@localhost> <7448004.siKCIqQqTi@sifl> <20121206161200.GA4340@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thursday, December 06, 2012 06:12:00 PM Michael S. Tsirkin wrote: > On Thu, Dec 06, 2012 at 10:46:11AM -0500, Paul Moore wrote: > > On Thursday, December 06, 2012 12:33:25 PM Michael S. Tsirkin wrote: > > > OK so just to verify: this can be used to ensure that qemu > > > process that has the queue fd can only attach it to > > > a specific device, right? > > > > Whenever a new queue is created via TUNSETQUEUE/tun_set_queue() the > > security_tun_dev_create_queue() LSM hook is called. When SELinux is > > enabled this hook ends up calling selinux_tun_dev_create_queue() which > > checks that the calling process (process_t) is allowed to create a new > > queue on the specified device (tundev_t) . If you are familiar with > > SELinux security policy, the allow rule would look like this: > > > > allow process_t tundev_t:tun_socket create_queue; > > > > In practice, if we assume libvirt is creating the TUN device and running > > with a SELinux label of virtd_t and that QEMU instances are running with > > a SELinux label of svirt_t then the allow rule would look like this: > > > > allow svirt_t virtd_t:tun_socket create_queue; > > > > There is also the matter of the MLS/MCS constraints providing additional > > separation but that is another level of detail which I don't believe is > > important for our discussion. > > Hmm. How do the rules for SETIFF look ATM? > I am just checking default policy does not let qemu do with > SETQUEUE something with a device which it can not > attach to using SETIFF. The SETQUEUE/tun_socket:create_queue permissions do not yet exist in any released SELinux policy as we are just now adding them with this patchset. With current policies loaded into a kernel with this patchset applied the SETQUEUE/tun_socket:create_queue permission would be treated according to the policy's unknown permission setting. -- paul moore security and virtualization @ redhat -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.