linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Justin P. Mattock" <justinmattock@gmail.com>
To: Paul Moore <paul.moore@hp.com>
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: netlabel: UNLABELED ath9k not denying unlabeled traffic
Date: Wed, 14 Jan 2009 13:35:25 -0800	[thread overview]
Message-ID: <496E5A9D.3050105@gmail.com> (raw)
In-Reply-To: <200901141508.58174.paul.moore@hp.com>

Paul Moore wrote:
> On Wednesday 14 January 2009 3:04:30 pm Paul Moore wrote:
>   
>> On Wednesday 14 January 2009 12:32:35 pm Justin P. Mattock wrote:
>>     
>
> ...
>
>   
>>>>> The next is a macbookpro ati chipset the kernel is 2.6.29-rc1
>>>>> the o.s. is ubuntu jaunty, the netlabel_tools is the same as
>>>>> above. the only results I see out of this is the avc's it's
>>>>> generating (the allow rules above are from the macbook);
>>>>> some reason the dell doesn't generate any avc's,
>>>>> which makes me wonder is this a module issue.
>>>>>           
>>>> Huh.  Just so I'm clear on this ... on the macbook you see avc
>>>> denials that correspond to the allow rules you posted above, but
>>>> on the dell you don't see the same avc denials?  Are you running
>>>> the same SELinux policy on both systems (version numbers)?  What
>>>> is the output of the following command on both systems?
>>>>
>>>>  # cat /selinux/policy_capabilities/network_peer_controls
>>>>         
>>> for both systems I'm running the refpolicy(svn) from tresys.
>>> the new ubac options, and newrole mechanism etc..
>>> doing cat /selinux/policy_capabilities_netowork_peer_controls says
>>> "1" should be for both.
>>>       
>> Ahhhh!  How did that happen?!  (see my response to your other email)
>>     
>
> Sorry, just realized your other email was private.  In case anyone else 
> is following this thread, the SELinux policy for network_peer_controls 
> policy capability is still a work in progress and is disabled by 
> default because there are still a few issues remaining.  Disabling the 
> network_peer_controls (the default configuration) fixed the problem.
>
>   
Cool, that's what I figured when looking at cipsov4.
As for the namespace term(yeah I don't know the term; ahh different
domain's or mappings I think);
Anyways heres what I'm trying to achieve:

default looks like this:
Configured NetLabel domain mappings(1)
domain: DEFAULT
    protocol: UNLABELED

I want to try and have three of these for the
different types of media:
(in theory)
Configured NetLabel domain mappings(3)
domain:radio
   protocol: UNLABELED
domain:T.V.
   protocol: UNLABELED
domain:web
   protocol: UNLABELED
(and if possible three different tags(either 1,2,5), but probably can
only do that with cipsov4);

heres what I've come up with so far:

netlabelctl -p map del default

netlabelctl unlbl add domain:radio interface:wlan0 address:<myadd> 
label:system_u:object_r:netlabel_peer_t:s0
netlabelctl unlbl add domain:radio interface:wlan0 address:<radioadd> 
label:system_u:object_r:netlabel_peer_t:s0

netlabelctl unlbl add domain:T.V. interface:wlan0 address:<myadd> 
label:system_u:object_r:netlabel_peer_t:s0
netlabelctl unlbl add domain:T.V. interface:wlan0 address:<t.v.add> 
label:system_u:object_r:netlabel_peer_t:s0

As for the new capabilities, I don't mind trying that out when
the time comes(but first I need to figure the this out before any other 
ways);

here is what the error looks like:

netlabel_tools-0.19# make
INFO: creating the version header file
.: 10: version_info: not found
make: *** [include/version.h] Error 2

(googling for the missing package results in a bunch of
hits on "just do a uname -r");

In any case using the default, and then just adding
addresses is probably fine for the time being.

regards;

Justin P. Mattock




  reply	other threads:[~2009-01-14 21:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <496D759A.7010401@gmail.com>
     [not found] ` <200901140957.09722.paul.moore@hp.com>
2009-01-14 16:15   ` netlabel: UNLABELED ath9k not denying unlabeled traffic Justin P. Mattock
2009-01-14 17:05     ` Paul Moore
2009-01-14 17:32       ` Justin P. Mattock
2009-01-14 20:04         ` Paul Moore
2009-01-14 20:08           ` Paul Moore
2009-01-14 21:35             ` Justin P. Mattock [this message]
2009-01-14 22:36               ` Paul Moore
2009-01-15  1:54                 ` Justin P. Mattock
2009-01-15 17:45                   ` Paul Moore
2009-01-15  2:43                 ` Justin P. Mattock
2009-01-15 17:46                   ` Paul Moore
2009-01-15 22:00                     ` Justin Mattock
2009-01-15 22:52                       ` Paul Moore
2009-01-16  0:44                         ` Justin Mattock
2009-01-16 16:09                           ` Paul Moore
2009-01-16 17:18                             ` Justin P. Mattock

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=496E5A9D.3050105@gmail.com \
    --to=justinmattock@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).