From: Paul Moore <pmoore@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH v3 2/2] tun: fix LSM/SELinux labeling of tun/tap devices
Date: Wed, 19 Dec 2012 11:58:10 -0500 [thread overview]
Message-ID: <2374585.ppB8RWyPuB@sifl> (raw)
In-Reply-To: <50D154B1.4010909@redhat.com>
On Wednesday, December 19, 2012 01:46:25 PM Jason Wang wrote:
> On 12/19/2012 07:08 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 18, 2012 at 05:53:52PM -0500, Paul Moore wrote:
> >> This patch corrects some problems with LSM/SELinux that were introduced
> >> with the multiqueue patchset. The problem stems from the fact that the
> >> multiqueue work changed the relationship between the tun device and its
> >> associated socket; before the socket persisted for the life of the
> >> device, however after the multiqueue changes the socket only persisted
> >> for the life of the userspace connection (fd open). For non-persistent
> >> devices this is not an issue, but for persistent devices this can cause
> >> the tun device to lose its SELinux label.
> >>
> >> We correct this problem by adding an opaque LSM security blob to the
> >> tun device struct which allows us to have the LSM security state, e.g.
> >> SELinux labeling information, persist for the lifetime of the tun
> >> device. In the process we tweak the LSM hooks to work with this new
> >> approach to TUN device/socket labeling and introduce a new LSM hook,
> >> security_tun_dev_attach_queue(), to approve requests to attach to a
> >> TUN queue via TUNSETQUEUE.
> >>
> >> The SELinux code has been adjusted to match the new LSM hooks, the
> >> other LSMs do not make use of the LSM TUN controls. This patch makes
> >> use of the recently added "tun_socket:attach_queue" permission to
> >> restrict access to the TUNSETQUEUE operation. On older SELinux
> >> policies which do not define the "tun_socket:attach_queue" permission
> >> the access control decision for TUNSETQUEUE will be handled according
> >> to the SELinux policy's unknown permission setting.
> >>
> >> Signed-off-by: Paul Moore <pmoore@redhat.com>
> >
> > Looks good to me. A comment not directly related to this patch, below.
>
> Good to me too, will do some test on this.
Great. I'll do some more testing and make sure the LSM and SELinux crowd are
okay with the changes.
--
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.
next prev parent reply other threads:[~2012-12-19 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-18 22:53 [RFC PATCH v3 0/2] Fix some multiqueue TUN problems Paul Moore
2012-12-18 22:53 ` [RFC PATCH v3 1/2] selinux: add the "attach_queue" permission to the "tun_socket" class Paul Moore
2012-12-18 22:53 ` [RFC PATCH v3 2/2] tun: fix LSM/SELinux labeling of tun/tap devices Paul Moore
[not found] ` <20121218230808.GC1135@redhat.com>
[not found] ` <50D154B1.4010909@redhat.com>
2012-12-19 16:58 ` Paul Moore [this message]
2012-12-20 21:58 ` Eric Paris
2012-12-19 16:59 ` [RFC PATCH v3 0/2] Fix some multiqueue TUN problems 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=2374585.ppB8RWyPuB@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.