linux-kernel - Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <496E5A9D.3050105@gmail.com>
Date:	Wed, 14 Jan 2009 13:35:25 -0800
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Paul Moore <paul.moore@...com>
CC:	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
	SE-Linux <selinux@...ho.nsa.gov>
Subject: Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/