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. The current DAC code exists in tun_not_capable(). -- 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
