From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Paul Moore <paul.moore@hp.com>
Cc: eparis@redhat.com, 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 21:15:58 -0500 [thread overview]
Message-ID: <20090806021558.GA17998@us.ibm.com> (raw)
In-Reply-To: <200908051758.39051.paul.moore@hp.com>
Quoting Paul Moore (paul.moore@hp.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.
I see the question being asked as: Does this device belong to
the caller and, if not, is the caller privileged to act
anyway?' So I think the capable call should be moved back
into the tun driver, followed by a separate security_tun_dev_attach()
check, since that is a separate, restrictive question.
thanks,
-serge
--
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: "Serge E. Hallyn" <serue@us.ibm.com>
To: Paul Moore <paul.moore@hp.com>
Cc: eparis@redhat.com, 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 21:15:58 -0500 [thread overview]
Message-ID: <20090806021558.GA17998@us.ibm.com> (raw)
In-Reply-To: <200908051758.39051.paul.moore@hp.com>
Quoting Paul Moore (paul.moore@hp.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.
I see the question being asked as: Does this device belong to
the caller and, if not, is the caller privileged to act
anyway?' So I think the capable call should be moved back
into the tun driver, followed by a separate security_tun_dev_attach()
check, since that is a separate, restrictive question.
thanks,
-serge
next prev parent reply other threads:[~2009-08-06 2:16 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
2009-08-05 21:58 ` Paul Moore
2009-08-06 2:15 ` Serge E. Hallyn [this message]
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=20090806021558.GA17998@us.ibm.com \
--to=serue@us.ibm.com \
--cc=eparis@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
--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.