public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <pmoore@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
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 16:09:51 -0500	[thread overview]
Message-ID: <1761265.vEQbM1ySnW@sifl> (raw)
In-Reply-To: <20121206205716.GA6576@redhat.com>

On Thursday, December 06, 2012 10:57:16 PM Michael S. Tsirkin wrote:
> On Thu, Dec 06, 2012 at 11:56:45AM -0500, Paul Moore wrote:
> > 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.
> 
> OK I think we need to rethink what we are doing here: what you sent
> addresses the problem as stated but I think we mis-stated it.  Let me
> try to restate the problem: it is not just selinux problem. Let's assume
> qemu wants to use tun, I (libvirt) don't want to run it as root.
> 
> 1. TUNSETIFF: I can open tun, attach an fd and pass it to qemu.
> Now, qemu does not invoke TUNSETIFF so it can run without
> kernel priveledges.

Correct me if I'm wrong, but I believe libvirt does this while running as 
root.  Assuming that is the case, why not simply setuid()/setgid() to the same 
credentials as the QEMU instance before creating the TUN device?  You can 
always (re)configure the device afterwards while running as 
root/CAP_NET_ADMIN.
 
> 2. TUNSETQUEUE - I can open tun and attach a queue but this
> is not what is needed since this automatically switches
> to multiqueue mode - we want to change number of queues
> on the fly.
> So qemu needs to be allowed to run TUNSETQUEUE.
> Since this checks tun_not_capable(tun) we would need
> to give qemu these priveledges, and we want to avoid this
> (I can go into why if it's not obvious).

If libvirt creates the TUN device while its effective credentials match those 
of the QEMU instance then the QEMU instance should be able to perform a 
TUNSETQUEUE, yes?

> How can we slove this?
> I don't see a way without extending the interface.
> Here's a simple way to extend it: pass a flag to TUNSETQUEUE
> that enables/disables TX on this queue.
> If TX is disabled, ignore this queue for flow steering decisions.
> Allow TUNSETQUEUE for a non priveledged user if it
> it already bound to the currect tun and only changes this flag.
> 
> Now I open tun and SETQUEUE with TX disabled flag. Pass it to qemu.
> qemu calls SETQUEUE with TX enabled flag.
> 
> Jason? Want to try implementing and see what people think?

-- 
paul moore
security and virtualization @ redhat

  reply	other threads:[~2012-12-06 21:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05 20:25 [RFC PATCH v2 0/3] Fix some multiqueue TUN problems Paul Moore
2012-12-05 20:26 ` [RFC PATCH v2 1/3] tun: correctly report an error in tun_flow_init() Paul Moore
2012-12-06 10:31   ` Jason Wang
2012-12-06 15:46     ` Paul Moore
2012-12-05 20:26 ` [RFC PATCH v2 2/3] selinux: add the "create_queue" permission to the "tun_socket" class Paul Moore
2012-12-05 20:26 ` [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices Paul Moore
2012-12-06 10:29   ` Jason Wang
2012-12-06 15:36     ` Paul Moore
2012-12-07  5:29       ` Jason Wang
2012-12-06 10:33   ` Michael S. Tsirkin
2012-12-06 13:51     ` Jason Wang
2012-12-06 14:12       ` Michael S. Tsirkin
2012-12-06 15:46     ` Paul Moore
2012-12-06 16:12       ` Michael S. Tsirkin
2012-12-06 16:56         ` Paul Moore
2012-12-06 20:57           ` Michael S. Tsirkin
2012-12-06 21:09             ` Paul Moore [this message]
2012-12-07 12:25               ` Michael S. Tsirkin
2012-12-10 17:04                 ` Paul Moore
2012-12-10 17:26                   ` Michael S. Tsirkin
2012-12-10 17:33                     ` Paul Moore
2012-12-10 17:50                       ` Michael S. Tsirkin
2012-12-10 18:42                         ` Eric Paris
2012-12-10 22:21                           ` Paul Moore
2012-12-10 22:43                         ` Paul Moore
2012-12-11  6:41                           ` Jason Wang
2012-12-12  9:10                           ` Michael S. Tsirkin
2012-12-07  5:41             ` Jason Wang
2012-12-12  9:22   ` Michael S. Tsirkin
2012-12-12 18:49     ` Paul Moore

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=1761265.vEQbM1ySnW@sifl \
    --to=pmoore@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=selinux@tycho.nsa.gov \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox