Re: tun/tap and SE Linux in 2.6.32

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-12-10 at 07:56 +1100, Russell Coker wrote:
> On Thu, 10 Dec 2009, Paul Moore <paul.moore@xxxxxx> 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.

That would require changing avc_has_perm_noaudit() or
context_struct_compute_av(), which historically have not treated an
error condition (e.g. invalid SID or class) within *compute_av() in the
same manner as lack of permission in the policy.  In the error condition
case, avc_has_perm_noaudit() just propagates the error condition to the
caller and permissive mode doesn't come into play - it doesn't even look
at (or cache) the av_decision.

That said, we've long since made the invalid SID case unreachable
(automatic remapping to the unlabeled SID), and we've now made the
invalid class case only an error if handle_unknown==deny, so possibly we
could change *compute_av() or avc_has_perm() to treat it the same way as
a regular permission denial.  We could possibly make *compute_av()
always "succeed" and just return the empty allowed vector (already
cleared on entry) on all error conditions, in which case avc_has_perm()
would always do the right thing.  And *compute_av() would become void
functions then.

-- 
Stephen Smalley
National Security Agency


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

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux