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
next prev parent 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).