From: Paul Moore <paul.moore@hp.com>
To: russell@coker.com.au
Cc: Stephen Smalley <sds@epoch.ncsc.mil>, "SE-Linux" <selinux@tycho.nsa.gov>
Subject: Re: tun/tap and SE Linux in 2.6.32
Date: Wed, 9 Dec 2009 16:45:46 -0500 [thread overview]
Message-ID: <200912091645.46800.paul.moore@hp.com> (raw)
In-Reply-To: <200912100756.24553.russell@coker.com.au>
On Wednesday 09 December 2009 03:56:22 pm Russell Coker wrote:
> On Thu, 10 Dec 2009, Paul Moore <paul.moore@hp.com> wrote:
> > > Subject: selinux PERMISSIVE blocking tun/tap device creation in v2.6.32
> >
> > I imagine this is because the original reporter is using a SELinux policy
> > without the new TUN socket classes/permissions (which is likely the
> > common case at this point). The unknown class/permission handling that
> > Eric added _should_ protect us from this - Russel do you have any more
> > information about the distribution and policy in use here?
>
> Sorry, the original message apparently wasn't clear enough (I've added some
> caps).
>
> The problem occurred in permissive mode. When the system is in permissive
> mode then SE Linux should not deny any action that Unix permissions will
> permit.
Yes, I agree. The avc_has_perm_noaudit() function, which is called by
avc_has_perm(), checks to see if the system is in enforcing or permissive mode
and does the right thing ... except for one case that I can see, the case
where security_compute_av() returns an error/non-zero value.
Looking at security_compute_av() there is definitely code that will return an
error, even the EINVAL that was reported, but it would appear to only be
possible if the allow unknown classes/permissions flag was set to "no". Could
you please verify with the original reporter that this is the case? It would
also be interesting to see which distribution is shipping policy that has this
flag set to "no".
requested = unmap_perm(orig_tclass, orig_requested);
tclass = unmap_class(orig_tclass);
if (unlikely(orig_tclass && !tclass)) {
if (policydb.allow_unknown)
goto allow;
rc = -EINVAL;
goto out;
}
As for fixing this, there are a few options that I can think of, one of which
is to change avc_has_perm_noaudit() so that it does not return a error code,
only access denials.
--
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.
prev parent reply other threads:[~2009-12-09 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 1:32 tun/tap and SE Linux in 2.6.32 Russell Coker
2009-12-09 20:48 ` Paul Moore
2009-12-09 20:56 ` Russell Coker
2009-12-09 21:26 ` Stephen Smalley
2009-12-09 21:45 ` Paul Moore [this message]
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=200912091645.46800.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=russell@coker.com.au \
--cc=sds@epoch.ncsc.mil \
--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.