All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>, eparis@redhat.com
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
Date: Wed, 5 Aug 2009 17:58:38 -0400	[thread overview]
Message-ID: <200908051758.39051.paul.moore@hp.com> (raw)
In-Reply-To: <20090805141350.GA353@us.ibm.com>

On Wednesday 05 August 2009 10:13:50 am Serge E. Hallyn wrote:
> Quoting Paul Moore (paul.moore@hp.com):

[NOTE: my email has been out all day due to some mysterious FS issue so my 
apologies for not replying sooner]

...

> The checks before and after this patch are not equivalent.  Post-patch,
> one must always have CAP_NET_ADMIN to do the attach, whereas pre-patch
> you only needed those if current_cred() did not own the tun device.  Is
> that intentional?

Nope, just a goof on my part; I misread the booleans and haven't fully tested 
the patch yet so it slipped out, thanks for catching it.  This brings up a 
good point, would we rather move the TUN owner/group checks into the cap_tun_* 
functions or move the capable() call back into the TUN driver?  The answer 
wasn't clear to me when I was looking at the code before and the uniqueness of 
the TUN driver doesn't help much in this regard.

> Also as Eric said this patch needs to set the cap_ hooks.  This patch
> isn't yet introducing the selinux hooks, so iiuc actually this patch should
> always oops if CONFIG_SECURITY=y.

Yep, another symptom of not enough testing as I mentioned out in the original 
posting, thanks to both of you for pointing this out ... now somebody just 
needs to fix Rawhide so I can actually get a KVM instance running :)

-- 
paul moore
linux @ hp


--
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.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul.moore@hp.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>, eparis@redhat.com
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
Date: Wed, 5 Aug 2009 17:58:38 -0400	[thread overview]
Message-ID: <200908051758.39051.paul.moore@hp.com> (raw)
In-Reply-To: <20090805141350.GA353@us.ibm.com>

On Wednesday 05 August 2009 10:13:50 am Serge E. Hallyn wrote:
> Quoting Paul Moore (paul.moore@hp.com):

[NOTE: my email has been out all day due to some mysterious FS issue so my 
apologies for not replying sooner]

...

> The checks before and after this patch are not equivalent.  Post-patch,
> one must always have CAP_NET_ADMIN to do the attach, whereas pre-patch
> you only needed those if current_cred() did not own the tun device.  Is
> that intentional?

Nope, just a goof on my part; I misread the booleans and haven't fully tested 
the patch yet so it slipped out, thanks for catching it.  This brings up a 
good point, would we rather move the TUN owner/group checks into the cap_tun_* 
functions or move the capable() call back into the TUN driver?  The answer 
wasn't clear to me when I was looking at the code before and the uniqueness of 
the TUN driver doesn't help much in this regard.

> Also as Eric said this patch needs to set the cap_ hooks.  This patch
> isn't yet introducing the selinux hooks, so iiuc actually this patch should
> always oops if CONFIG_SECURITY=y.

Yep, another symptom of not enough testing as I mentioned out in the original 
posting, thanks to both of you for pointing this out ... now somebody just 
needs to fix Rawhide so I can actually get a KVM instance running :)

-- 
paul moore
linux @ hp


  reply	other threads:[~2009-08-05 21:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04 21:21 [RFC PATCH v1 0/2] The Long Lost TUN LSM Hooks Paul Moore
2009-08-04 21:21 ` Paul Moore
2009-08-04 21:21 ` [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver Paul Moore
2009-08-04 21:21   ` Paul Moore
2009-08-05 13:03   ` Eric Paris
2009-08-05 13:03     ` Eric Paris
2009-08-05 14:13   ` Serge E. Hallyn
2009-08-05 14:13     ` Serge E. Hallyn
2009-08-05 21:58     ` Paul Moore [this message]
2009-08-05 21:58       ` Paul Moore
2009-08-06  2:15       ` Serge E. Hallyn
2009-08-06  2:15         ` Serge E. Hallyn
2009-08-06 14:24         ` Paul Moore
2009-08-06 14:24           ` Paul Moore
2009-08-06 15:52           ` Serge E. Hallyn
2009-08-06 15:52             ` Serge E. Hallyn
2009-08-06 16:25             ` Paul Moore
2009-08-06 16:25               ` Paul Moore
2009-08-06 18:38               ` Serge E. Hallyn
2009-08-06 18:38                 ` Serge E. Hallyn
2009-08-04 21:22 ` [RFC PATCH v1 2/2] selinux: Support for the new TUN LSM hooks Paul Moore
2009-08-04 21:22   ` Paul Moore
2009-08-05 13:06   ` Eric Paris
2009-08-05 13:06     ` Eric Paris
2009-08-05  0:43 ` [RFC PATCH v1 0/2] The Long Lost TUN LSM Hooks James Morris
2009-08-05  0:43   ` James Morris

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=200908051758.39051.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=eparis@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=selinux@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    /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.