netlabel: UNLABELED ath9k not denying unlabeled traffic

netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

When using netlabelctl on a dell laptop
I'm able to define the addresses that I want:

netlabelctl unlbl add interface:wlan0 address:<radiostation> 
label:system_u:object_r:netlabel_peer_t:s0
netlabelctl unlbl add interface:wlan0 address:<myaddress> 
label:system_u:object_r:netlabel_peer_t:s0
netlabelctl  -p unlbl accept off

{the above was from http://paulmoore.livejournal.com/1758.html };
(I'm able to listen to the radio station allowed, then if I choose 
another station; if I haven't defined an address like the above, mplayer 
just sits there.denying the unlabeled packet. that is until I allow the 
address);

The problem I have is when I do the same on my macbook pro ati chipset.
with the ath9k module, I'm able to listen to any station, search the web 
etc..
it seems netlabelctl  -p unlbl accept off makes no difference if it's on 
or off.
 
Is this built into ath9k yet, or is there something I'm missing?

regards;

Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 12:18:18 am Justin P. Mattock wrote:
> When using netlabelctl on a dell laptop
> I'm able to define the addresses that I want:
>
> netlabelctl unlbl add interface:wlan0 address:<radiostation>
> label:system_u:object_r:netlabel_peer_t:s0
> netlabelctl unlbl add interface:wlan0 address:<myaddress>
> label:system_u:object_r:netlabel_peer_t:s0
> netlabelctl  -p unlbl accept off
>
> {the above was from http://paulmoore.livejournal.com/1758.html };

Hey, somebody actually reads that stuff!  I guess I'll need to be 
careful what I write from now on :)

Hi Justin, on a more serious note, if you are having problems with 
labeled networking it's probably a good idea to CC the SELinux, LSM 
and/or netdev lists depending on the issue as I often miss mail if it 
is only posted to LKML.  When in doubt you can just CC me personally 
(paul.moore@hp.com) and I'll add whatever list seems appropriate.

> (I'm able to listen to the radio station allowed, then if I choose
> another station; if I haven't defined an address like the above,
> mplayer just sits there.denying the unlabeled packet. that is until I
> allow the address);

Good, that is how it should work give the configuration shown above.

> The problem I have is when I do the same on my macbook pro ati
> chipset. with the ath9k module, I'm able to listen to any station,
> search the web etc..
> it seems netlabelctl  -p unlbl accept off makes no difference if it's
> on or off.
>
> Is this built into ath9k yet, or is there something I'm missing?

That is just plain odd, there isn't really anything that is driver 
specific.  Can you share any more details like kernel version, 
netlabel_tools verion, distro, etc?  I don't have any ath9k hardware 
lying around to test so I would appreciate whatever additional 
information you can provide.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

Paul Moore wrote:
> On Wednesday 14 January 2009 12:18:18 am Justin P. Mattock wrote:
>   
>> When using netlabelctl on a dell laptop
>> I'm able to define the addresses that I want:
>>
>> netlabelctl unlbl add interface:wlan0 address:<radiostation>
>> label:system_u:object_r:netlabel_peer_t:s0
>> netlabelctl unlbl add interface:wlan0 address:<myaddress>
>> label:system_u:object_r:netlabel_peer_t:s0
>> netlabelctl  -p unlbl accept off
>>
>> {the above was from http://paulmoore.livejournal.com/1758.html };
>>     
>
> Hey, somebody actually reads that stuff!  I guess I'll need to be 
> careful what I write from now on :)
>
> Hi Justin, on a more serious note, if you are having problems with 
> labeled networking it's probably a good idea to CC the SELinux, LSM 
> and/or netdev lists depending on the issue as I often miss mail if it 
> is only posted to LKML.  When in doubt you can just CC me personally 
> (paul.moore@hp.com) and I'll add whatever list seems appropriate.
>
>   
>> (I'm able to listen to the radio station allowed, then if I choose
>> another station; if I haven't defined an address like the above,
>> mplayer just sits there.denying the unlabeled packet. that is until I
>> allow the address);
>>     
>
> Good, that is how it should work give the configuration shown above.
>
>   
>> The problem I have is when I do the same on my macbook pro ati
>> chipset. with the ath9k module, I'm able to listen to any station,
>> search the web etc..
>> it seems netlabelctl  -p unlbl accept off makes no difference if it's
>> on or off.
>>
>> Is this built into ath9k yet, or is there something I'm missing?
>>     
>
> That is just plain odd, there isn't really anything that is driver 
> specific.  Can you share any more details like kernel version, 
> netlabel_tools verion, distro, etc?  I don't have any ath9k hardware 
> lying around to test so I would appreciate whatever additional 
> information you can provide.
>
>   
Hey alright.(I finally got around to  trying netlabelctl out!).

The two systems I have for this are: Dell latitude x200
running ubuntu jaunty, kernel is 2.6.29-rc1.
with netlabel_tools_0.18 which was an rpm packaged
that I converted to .deb.(can't remember the repository where I grabbed 
it from);
The wireless card for the dell is a dell 1350
using bcmxx(b43-phy0); works great.

The results when using netlabelctl with the dell is nice, i.g. like I said
as soon as I issue netlabelctl unlbl accept off, those addresses not defined
are simply not allowed.(the problem with the dell is I'm not seeing
any allow rules being generated: i.g.

allow netlabel_peer_t netif_t:netif ingress;
allow netlabel_peer_t node_t:node recvfrom;
allow unlabeled_t netif_t:netif ingress;
allow unlabeled_t node_t:node recvfrom;

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.

Also I've gone through thinking, well maybe this is avc's driven,
i.g. each address once added by netlabelctl receives a certain allow rule
(like the allow rules above),
if not either no allow rule is given to it,resulting in a denial you 
can't see in dmesg,
or a denial that just won't be allowed by checkpolicy.
So after seeing if this was the case I was left with  an address defined by
netlabel(allowed) and defined the allow rules that it had created.
unfortunately after all of that I still was able to turn on another radio
station  that had  no  address  in netlabelctl's  unlbl database.(and no 
allow rule
with SELinux);
leading me to believe that the netlabel area or driver isn't working
properly. or just told to not enforce the netlabel accept off option.

As for the list, I have linux-wireless in my address book(not sure which 
is right);

regards;

Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 11:15:46 am Justin P. Mattock wrote:
> Paul Moore wrote:
> > On Wednesday 14 January 2009 12:18:18 am Justin P. Mattock wrote:
> >> When using netlabelctl on a dell laptop
> >> I'm able to define the addresses that I want:
> >>
> >> netlabelctl unlbl add interface:wlan0 address:<radiostation>
> >> label:system_u:object_r:netlabel_peer_t:s0
> >> netlabelctl unlbl add interface:wlan0 address:<myaddress>
> >> label:system_u:object_r:netlabel_peer_t:s0
> >> netlabelctl  -p unlbl accept off
> >>
> >> {the above was from http://paulmoore.livejournal.com/1758.html };
> >

...

> >> (I'm able to listen to the radio station allowed, then if I choose
> >> another station; if I haven't defined an address like the above,
> >> mplayer just sits there.denying the unlabeled packet. that is
> >> until I allow the address);
> >> The problem I have is when I do the same on my macbook pro ati
> >> chipset. with the ath9k module, I'm able to listen to any station,
> >> search the web etc..
> >> it seems netlabelctl  -p unlbl accept off makes no difference if
> >> it's on or off.
> >>
> >> Is this built into ath9k yet, or is there something I'm missing?
> >
> > That is just plain odd, there isn't really anything that is driver
> > specific.  Can you share any more details like kernel version,
> > netlabel_tools verion, distro, etc?  I don't have any ath9k
> > hardware lying around to test so I would appreciate whatever
> > additional information you can provide.
>
> Hey alright.(I finally got around to  trying netlabelctl out!).

It's pretty cool.  In newer versions of netlabelctl I added an 
undocumented option to actually allow it to fix a sandwhich and do the 
dishes afterwards.  The exact command line option needed is left as an 
exercise for the reader :)

> The two systems I have for this are: Dell latitude x200
> running ubuntu jaunty, kernel is 2.6.29-rc1.
> with netlabel_tools_0.18 which was an rpm packaged
> that I converted to .deb.(can't remember the repository where I
> grabbed it from);
> The wireless card for the dell is a dell 1350
> using bcmxx(b43-phy0); works great.

Great.  I'm not a debian user so I can't be of much help on the 
packaging side, but you can get raw tarballs from the NetLabel project 
site on SF (the current release is 0.19 which includes support for all 
the goodies in 2.6.28):

 * http://netlabel.sf.net

> The results when using netlabelctl with the dell is nice, i.g. like I
> said as soon as I issue netlabelctl unlbl accept off, those addresses
> not defined are simply not allowed.(the problem with the dell is I'm
> not seeing any allow rules being generated: i.g.
>
> allow netlabel_peer_t netif_t:netif ingress;
> allow netlabel_peer_t node_t:node recvfrom;
> allow unlabeled_t netif_t:netif ingress;
> allow unlabeled_t node_t:node recvfrom;

[NOTE: the rules/permissions you list above are the "newer" network_peer 
permissions which are likely not active unless you are running a custom 
SELinux policy as the default Reference Policy hasn't made the switch 
yet to the newer system]

The netlabelctl tool doesn't generate any allow rules, all it does is 
configure the NetLabel subsystem which is all that is necessary 
because, this is important, NetLabel doesn't actually do any network 
traffic enforcement.  NetLabel is a network labeling framework, which 
means that it only deals with setting labels on outbound network 
packets and retrieving labels from inbound network packets 
(the "netlabel unlbl accept on|off" option is a gray area).  The 
decision about wether to accept or reject inbound network traffic is 
left to the LSM (NetLabel supports both SELinux and Smack).  If you 
want I can go into more detail but it would probably be rather boring 
and not really provide you much in the way of answering your question.

> 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

> Also I've gone through thinking, well maybe this is avc's driven,
> i.g. each address once added by netlabelctl receives a certain allow
> rule (like the allow rules above),
> if not either no allow rule is given to it,resulting in a denial you
> can't see in dmesg,
> or a denial that just won't be allowed by checkpolicy.
> So after seeing if this was the case I was left with  an address
> defined by netlabel(allowed) and defined the allow rules that it had
> created. unfortunately after all of that I still was able to turn on
> another radio station  that had  no  address  in netlabelctl's  unlbl
> database.(and no allow rule
> with SELinux);
> leading me to believe that the netlabel area or driver isn't working
> properly. or just told to not enforce the netlabel accept off option.

Well, like I said above, it shouldn't be a policy module or allow rule 
problem but I think you may be right in that the SELinux policy is a 
good place to start looking.  Compare the policy on the two systems to 
see if they are the same version and check to see if the new network 
peer controls are active (the cat command above; 0 is disabled, 1 is 
enabled).  Post what you find out.

> As for the list, I have linux-wireless in my address book(not sure
> which is right);

Not sure linux-wireless will have much to do about this but you included 
the SELinux which is good, thank you.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

Paul Moore wrote:
> On Wednesday 14 January 2009 11:15:46 am Justin P. Mattock wrote:
>   
>> Paul Moore wrote:
>>     
>>> On Wednesday 14 January 2009 12:18:18 am Justin P. Mattock wrote:
>>>       
>>>> When using netlabelctl on a dell laptop
>>>> I'm able to define the addresses that I want:
>>>>
>>>> netlabelctl unlbl add interface:wlan0 address:<radiostation>
>>>> label:system_u:object_r:netlabel_peer_t:s0
>>>> netlabelctl unlbl add interface:wlan0 address:<myaddress>
>>>> label:system_u:object_r:netlabel_peer_t:s0
>>>> netlabelctl  -p unlbl accept off
>>>>
>>>> {the above was from http://paulmoore.livejournal.com/1758.html };
>>>>         
>
> ...
>
>   
>>>> (I'm able to listen to the radio station allowed, then if I choose
>>>> another station; if I haven't defined an address like the above,
>>>> mplayer just sits there.denying the unlabeled packet. that is
>>>> until I allow the address);
>>>> The problem I have is when I do the same on my macbook pro ati
>>>> chipset. with the ath9k module, I'm able to listen to any station,
>>>> search the web etc..
>>>> it seems netlabelctl  -p unlbl accept off makes no difference if
>>>> it's on or off.
>>>>
>>>> Is this built into ath9k yet, or is there something I'm missing?
>>>>         
>>> That is just plain odd, there isn't really anything that is driver
>>> specific.  Can you share any more details like kernel version,
>>> netlabel_tools verion, distro, etc?  I don't have any ath9k
>>> hardware lying around to test so I would appreciate whatever
>>> additional information you can provide.
>>>       
>> Hey alright.(I finally got around to  trying netlabelctl out!).
>>     
>
> It's pretty cool.  In newer versions of netlabelctl I added an 
> undocumented option to actually allow it to fix a sandwhich and do the 
> dishes afterwards.  The exact command line option needed is left as an 
> exercise for the reader :)
>   
yep, it is pretty cool.
ultimately my goal with netlabel is to see if I can setup the network
namespace(if this is proper to say).
 i.g. have all the radio stations in its own domain,(and possibly it's 
own tag,doi etc..)
and then have all T.V. stations running in its own domain. and then web 
searching in its own domain.
I see cipsov4 does this, but not sure if it does what the UNLABEL 
domain/protocol does.
(just looking at cipsov4; look like ipsec, you need two computers setup 
with the same domain and tag etc..)
not too sure though.
>   
>> The two systems I have for this are: Dell latitude x200
>> running ubuntu jaunty, kernel is 2.6.29-rc1.
>> with netlabel_tools_0.18 which was an rpm packaged
>> that I converted to .deb.(can't remember the repository where I
>> grabbed it from);
>> The wireless card for the dell is a dell 1350
>> using bcmxx(b43-phy0); works great.
>>     
>
> Great.  I'm not a debian user so I can't be of much help on the 
> packaging side, but you can get raw tarballs from the NetLabel project 
> site on SF (the current release is 0.19 which includes support for all 
> the goodies in 2.6.28):
>
>  * http://netlabel.sf.net
>   
I did grab that package but ran into the version_info
error,(resorted to the rpm out of desperation);
>   
>> The results when using netlabelctl with the dell is nice, i.g. like I
>> said as soon as I issue netlabelctl unlbl accept off, those addresses
>> not defined are simply not allowed.(the problem with the dell is I'm
>> not seeing any allow rules being generated: i.g.
>>
>> allow netlabel_peer_t netif_t:netif ingress;
>> allow netlabel_peer_t node_t:node recvfrom;
>> allow unlabeled_t netif_t:netif ingress;
>> allow unlabeled_t node_t:node recvfrom;
>>     
>
> [NOTE: the rules/permissions you list above are the "newer" network_peer 
> permissions which are likely not active unless you are running a custom 
> SELinux policy as the default Reference Policy hasn't made the switch 
> yet to the newer system]
>
> The netlabelctl tool doesn't generate any allow rules, all it does is 
> configure the NetLabel subsystem which is all that is necessary 
> because, this is important, NetLabel doesn't actually do any network 
> traffic enforcement.  NetLabel is a network labeling framework, which 
> means that it only deals with setting labels on outbound network 
> packets and retrieving labels from inbound network packets 
> (the "netlabel unlbl accept on|off" option is a gray area).  The 
> decision about wether to accept or reject inbound network traffic is 
> left to the LSM (NetLabel supports both SELinux and Smack).  If you 
> want I can go into more detail but it would probably be rather boring 
> and not really provide you much in the way of answering your question.
>   
boring to others, but to me, it's awesome.

>   
>> 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.
>   
>> Also I've gone through thinking, well maybe this is avc's driven,
>> i.g. each address once added by netlabelctl receives a certain allow
>> rule (like the allow rules above),
>> if not either no allow rule is given to it,resulting in a denial you
>> can't see in dmesg,
>> or a denial that just won't be allowed by checkpolicy.
>> So after seeing if this was the case I was left with  an address
>> defined by netlabel(allowed) and defined the allow rules that it had
>> created. unfortunately after all of that I still was able to turn on
>> another radio station  that had  no  address  in netlabelctl's  unlbl
>> database.(and no allow rule
>> with SELinux);
>> leading me to believe that the netlabel area or driver isn't working
>> properly. or just told to not enforce the netlabel accept off option.
>>     
>
> Well, like I said above, it shouldn't be a policy module or allow rule 
> problem but I think you may be right in that the SELinux policy is a 
> good place to start looking.  Compare the policy on the two systems to 
> see if they are the same version and check to see if the new network 
> peer controls are active (the cat command above; 0 is disabled, 1 is 
> enabled).  Post what you find out.
>   
they should be for both(uncommenting in 
/etc/selinux/refpolicy/policy/policy_capabilities
enables that option);

I think at this point I'm going to load an older kernel, with the madwifi
module(ath0) to isolate this issue i.g. if ath0 module reacts the same
as the dell does(when adding address and such); then this would point
me in the right direction. but if I receive the same response.
then maybe my libraries are messed up.
>   
>> As for the list, I have linux-wireless in my address book(not sure
>> which is right);
>>     
>
> Not sure linux-wireless will have much to do about this but you included 
> the SELinux which is good, thank you.
>
>   
overall I like this netlabel mechanism, hopefully I can get this
working properly.

regards;

Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 12:32:35 pm Justin P. Mattock wrote:
> Paul Moore wrote:
> > On Wednesday 14 January 2009 11:15:46 am Justin P. Mattock wrote:

...

> yep, it is pretty cool.
> ultimately my goal with netlabel is to see if I can setup the network
> namespace(if this is proper to say).

I understand what you are trying to say but I don't believe "namespace" 
is the term you want to use since it is already used by the container 
folks for something completely different.

>  i.g. have all the radio stations in its own domain,(and possibly
> it's own tag,doi etc..)
> and then have all T.V. stations running in its own domain. and then
> web searching in its own domain.

Yep, you can do that with NetLabel and the fallback/static labels like 
you've been doing.  Based on what I've seen from you so far, Secmark 
would also likely work for you but it takes a slightly different 
approach (configuration with iptables, different allow rules).

> I see cipsov4 does this, but not sure if it does what the UNLABEL
> domain/protocol does.
> (just looking at cipsov4; look like ipsec, you need two computers
> setup with the same domain and tag etc..)
> not too sure though.

Yep, CIPSO is a labeling protocol like labeled IPsec.  Both have their 
advantages and disadvantages but both require that the other end of the 
connection support the labeling protocol.  Since you are talking about 
labeling public network traffic it is almost certain that the other end 
of your connections don't support a network labeling protocol.  The 
fallback/static labeling capabilities of NetLabel (that is 
the "unlabeled/unlbl" protocol in NetLabel, it is "unlabeled" because 
there is no label present on the network traffic) was designed to solve 
this case for the network peer label case.  Secmark was designed to 
solve this for the iptables label case.

If you don't understand the difference between a network peer label and 
a network iptables label here is the executive summary:

 "A network peer label represents the security attributes of the
  traffic's sender, a iptables label represents the network
  attributes of the traffic."

... which basically means the peer label tells you about the 
process/host which generated the data (SELinux context, Smack label, 
etc.) while the iptables label tells you about the network headers of 
the traffic (destination address, protocol, port, anything that 
iptables/netfilter can match on).

> >> The two systems I have for this are: Dell latitude x200
> >> running ubuntu jaunty, kernel is 2.6.29-rc1.
> >> with netlabel_tools_0.18 which was an rpm packaged
> >> that I converted to .deb.(can't remember the repository where I
> >> grabbed it from);
> >> The wireless card for the dell is a dell 1350
> >> using bcmxx(b43-phy0); works great.
> >
> > Great.  I'm not a debian user so I can't be of much help on the
> > packaging side, but you can get raw tarballs from the NetLabel
> > project site on SF (the current release is 0.19 which includes
> > support for all the goodies in 2.6.28):
> >
> >  * http://netlabel.sf.net
>
> I did grab that package but ran into the version_info
> error,(resorted to the rpm out of desperation);

Hmm, can you show me the error?  I'd like to make sure it is fixed ...

> >> The results when using netlabelctl with the dell is nice, i.g.
> >> like I said as soon as I issue netlabelctl unlbl accept off, those
> >> addresses not defined are simply not allowed.(the problem with the
> >> dell is I'm not seeing any allow rules being generated: i.g.
> >>
> >> allow netlabel_peer_t netif_t:netif ingress;
> >> allow netlabel_peer_t node_t:node recvfrom;
> >> allow unlabeled_t netif_t:netif ingress;
> >> allow unlabeled_t node_t:node recvfrom;
> >
> > [NOTE: the rules/permissions you list above are the "newer"
> > network_peer permissions which are likely not active unless you are
> > running a custom SELinux policy as the default Reference Policy
> > hasn't made the switch yet to the newer system]
> >
> > The netlabelctl tool doesn't generate any allow rules, all it does
> > is configure the NetLabel subsystem which is all that is necessary
> > because, this is important, NetLabel doesn't actually do any
> > network traffic enforcement.  NetLabel is a network labeling
> > framework, which means that it only deals with setting labels on
> > outbound network packets and retrieving labels from inbound network
> > packets (the "netlabel unlbl accept on|off" option is a gray area).
> >  The decision about wether to accept or reject inbound network
> > traffic is left to the LSM (NetLabel supports both SELinux and
> > Smack).  If you want I can go into more detail but it would
> > probably be rather boring and not really provide you much in the
> > way of answering your question.
>
> boring to others, but to me, it's awesome.

I think so too :)

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

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

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.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

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

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
> 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);

Actually, in your case you are probably always going to want to send 
network traffic without any labels attached to the packets (no labeled 
IPsec or CIPSO) so you can stick with the default domain mapping 
configuration which sends all packets "unlabeled".  The part you should 
be concerned about is the static/fallback configuration which assigns 
network peer labels to packets which do not have labels attached to 
them by the remote host.

NOTE: the domain mapping configuration only controls how outbound 
network traffic is labeled on-the-wire; it "maps" the 
LSM/SELinux "domains" to a specific labeling protocol configuration, 
e.g. all apache_t traffic should be labeled with CIPSO DOI 3 while all 
firefox_t traffic should not be labeled at all.

> 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

I think what you mean to type is the following:

 # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
       label:system_u:object_r:netlabel_peer_t:s0

... note there is no "domain" argument, that only exists 
for "netlabelctl map ..." commands.

NOTE: if you really want to get fancy you can create new SELinux domains 
for each type of media and add NetLabel configurations for those new 
domains.  Imagine you create a new "internet_radio_t" domain/type and 
only allow the "netplayer_t" domain (yeah, I made that up but you get 
the point) access to network traffic labeled with internet_radio_t.  
You would then use the following command to label your incoming traffic 
with NetLabel:

 # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
       label:system_u:object_r:internet_radio_t:s0

NOTE: you can also skip the "interface:wlan0" argument and just 
use "default" instead if you want the configuration to apply to all 
your network interfaces; although bear in mind that the "default" 
configuration can be overridden by the interface specific 
configurations.

> 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);

No problem, I understand.  Let me know if you have any more problems.

> 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

Huh, can you try the following:

 1. Open the netlabel_tools-0.19/Makefile in your favorite editor
 2. Change the ". version_info; \" line to "source ./version_info; \"
 3. Save your changes
 4. Try running "make" again

Thanks.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

Paul Moore wrote:
> On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
>   
>> 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);
>>     
>
>   
apologize for the slow response
(had to do some external activities);
> Actually, in your case you are probably always going to want to send 
> network traffic without any labels attached to the packets (no labeled 
> IPsec or CIPSO) so you can stick with the default domain mapping 
> configuration which sends all packets "unlabeled".  The part you should 
> be concerned about is the static/fallback configuration which assigns 
> network peer labels to packets which do not have labels attached to 
> them by the remote host.
>   
sure would be nice to use ipsec/cipsov4 with a internet radio.
(lock down that tcp line);
I'll have to look into making sure I have static/fallback
configured correctly.
> NOTE: the domain mapping configuration only controls how outbound 
> network traffic is labeled on-the-wire; it "maps" the 
> LSM/SELinux "domains" to a specific labeling protocol configuration, 
> e.g. all apache_t traffic should be labeled with CIPSO DOI 3 while all 
> firefox_t traffic should not be labeled at all.
>
>   
>> 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
>>     
>
> I think what you mean to type is the following:
>
>  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
>        label:system_u:object_r:netlabel_peer_t:s0
>
> ... note there is no "domain" argument, that only exists 
> for "netlabelctl map ..." commands.
>
> NOTE: if you really want to get fancy you can create new SELinux domains 
> for each type of media and add NetLabel configurations for those new 
> domains.  Imagine you create a new "internet_radio_t" domain/type and 
> only allow the "netplayer_t" domain (yeah, I made that up but you get 
> the point) access to network traffic labeled with internet_radio_t.  
> You would then use the following command to label your incoming traffic 
> with NetLabel:
>
>  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
>        label:system_u:object_r:internet_radio_t:s0
>
> NOTE: you can also skip the "interface:wlan0" argument and just 
> use "default" instead if you want the configuration to apply to all 
> your network interfaces; although bear in mind that the "default" 
> configuration can be overridden by the interface specific 
> configurations.
>
>   
Alright, I thought you could use the map option for unlbl.

>> 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);
>>     
>
> No problem, I understand.  Let me know if you have any more problems.
>
>   
>> 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
>>     
>
> Huh, can you try the following:
>
>  1. Open the netlabel_tools-0.19/Makefile in your favorite editor
>  2. Change the ". version_info; \" line to "source ./version_info; \"
>  3. Save your changes
>  4. Try running "make" again
>
> Thanks.
>
>   
Thanks for the info,
Ill try this right away and let you know
if the package compiles.

regards;

Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

Paul Moore wrote:
> On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
>   
>> 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);
>>     
>
> Actually, in your case you are probably always going to want to send 
> network traffic without any labels attached to the packets (no labeled 
> IPsec or CIPSO) so you can stick with the default domain mapping 
> configuration which sends all packets "unlabeled".  The part you should 
> be concerned about is the static/fallback configuration which assigns 
> network peer labels to packets which do not have labels attached to 
> them by the remote host.
>
> NOTE: the domain mapping configuration only controls how outbound 
> network traffic is labeled on-the-wire; it "maps" the 
> LSM/SELinux "domains" to a specific labeling protocol configuration, 
> e.g. all apache_t traffic should be labeled with CIPSO DOI 3 while all 
> firefox_t traffic should not be labeled at all.
>
>   
>> 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
>>     
>
> I think what you mean to type is the following:
>
>  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
>        label:system_u:object_r:netlabel_peer_t:s0
>
> ... note there is no "domain" argument, that only exists 
> for "netlabelctl map ..." commands.
>
> NOTE: if you really want to get fancy you can create new SELinux domains 
> for each type of media and add NetLabel configurations for those new 
> domains.  Imagine you create a new "internet_radio_t" domain/type and 
> only allow the "netplayer_t" domain (yeah, I made that up but you get 
> the point) access to network traffic labeled with internet_radio_t.  
> You would then use the following command to label your incoming traffic 
> with NetLabel:
>
>  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
>        label:system_u:object_r:internet_radio_t:s0
>
> NOTE: you can also skip the "interface:wlan0" argument and just 
> use "default" instead if you want the configuration to apply to all 
> your network interfaces; although bear in mind that the "default" 
> configuration can be overridden by the interface specific 
> configurations.
>
>   
>> 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);
>>     
>
> No problem, I understand.  Let me know if you have any more problems.
>
>   
>> 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
>>     
>
> Huh, can you try the following:
>
>  1. Open the netlabel_tools-0.19/Makefile in your favorite editor
>  2. Change the ". version_info; \" line to "source ./version_info; \"
>  3. Save your changes
>  4. Try running "make" again
>
> Thanks.
>
>   
O.k. changed . version like how you had posted.
The package compiled like a charm.

regards;

Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 8:54:22 pm Justin P. Mattock wrote:
> Paul Moore wrote:
> apologize for the slow response
> (had to do some external activities);

No problem, I've got a day job too :)

> > NOTE: the domain mapping configuration only controls how outbound
> > network traffic is labeled on-the-wire; it "maps" the
> > LSM/SELinux "domains" to a specific labeling protocol
> > configuration, e.g. all apache_t traffic should be labeled with
> > CIPSO DOI 3 while all firefox_t traffic should not be labeled at
> > all.

...

> > I think what you mean to type is the following:
> >
> >  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
> >        label:system_u:object_r:netlabel_peer_t:s0
> >
> > ... note there is no "domain" argument, that only exists
> > for "netlabelctl map ..." commands.
> >
> > NOTE: if you really want to get fancy you can create new SELinux
> > domains for each type of media and add NetLabel configurations for
> > those new domains.  Imagine you create a new "internet_radio_t"
> > domain/type and only allow the "netplayer_t" domain (yeah, I made
> > that up but you get the point) access to network traffic labeled
> > with internet_radio_t. You would then use the following command to
> > label your incoming traffic with NetLabel:
> >
> >  # netlabelctl unlbl add interface:wlan0 address:<radioadd> \
> >        label:system_u:object_r:internet_radio_t:s0
> >
> > NOTE: you can also skip the "interface:wlan0" argument and just
> > use "default" instead if you want the configuration to apply to all
> > your network interfaces; although bear in mind that the "default"
> > configuration can be overridden by the interface specific
> > configurations.
>
> Alright, I thought you could use the map option for unlbl.

Yes, you can use configure the LSM/SELinux domain mapping to send 
unlabeled/"unlbl" packets (the default configuration maps all outbound 
traffic to "unlbl") but since you only really care about inbound 
traffic you can ignore the "map" option.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Wednesday 14 January 2009 9:43:56 pm Justin P. Mattock wrote:
> Paul Moore wrote:
> > On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
> >> 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
> >
> > Huh, can you try the following:
> >
> >  1. Open the netlabel_tools-0.19/Makefile in your favorite editor
> >  2. Change the ". version_info; \" line to "source ./version_info;
> > \" 3. Save your changes
> >  4. Try running "make" again
> >
> > Thanks.
>
> O.k. changed . version like how you had posted.
> The package compiled like a charm.

Great, I'll change the Makefile(s) in SVN ... I don't quite understand 
the reason (what is your /bin/sh?  I'm guessing not bash?) but at least 
we now have a solution :) 

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin Mattock]

On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <paul.moore@hp.com> wrote:
> On Wednesday 14 January 2009 9:43:56 pm Justin P. Mattock wrote:
>> Paul Moore wrote:
>> > On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
>> >> 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
>> >
>> > Huh, can you try the following:
>> >
>> >  1. Open the netlabel_tools-0.19/Makefile in your favorite editor
>> >  2. Change the ". version_info; \" line to "source ./version_info;
>> > \" 3. Save your changes
>> >  4. Try running "make" again
>> >
>> > Thanks.
>>
>> O.k. changed . version like how you had posted.
>> The package compiled like a charm.
>
> Great, I'll change the Makefile(s) in SVN ... I don't quite understand
> the reason (what is your /bin/sh?  I'm guessing not bash?) but at least
> we now have a solution :)
>
> --
> paul moore
> linux @ hp
>

hmm..
under ps auxZ
I see:
2896 tty1 S+ 0:00 /bin/bash /usr/bin/startx
then open aterm for navigating.

Thankfully it works(this people can install
it a test it out.)

regards;

-- 
Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Thursday 15 January 2009 5:00:55 pm Justin Mattock wrote:
> On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <paul.moore@hp.com> wrote:
> > On Wednesday 14 January 2009 9:43:56 pm Justin P. Mattock wrote:
> >> Paul Moore wrote:
> >> > On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
> >> >> 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
> >> >
> >> > Huh, can you try the following:
> >> >
> >> >  1. Open the netlabel_tools-0.19/Makefile in your favorite
> >> > editor 2. Change the ". version_info; \" line to "source
> >> > ./version_info; \" 3. Save your changes
> >> >  4. Try running "make" again
> >> >
> >> > Thanks.
> >>
> >> O.k. changed . version like how you had posted.
> >> The package compiled like a charm.
> >
> > Great, I'll change the Makefile(s) in SVN ... I don't quite
> > understand the reason (what is your /bin/sh?  I'm guessing not
> > bash?) but at least we now have a solution :)
> >
> > --
> > paul moore
> > linux @ hp
>
> hmm..
> under ps auxZ
> I see:
> 2896 tty1 S+ 0:00 /bin/bash /usr/bin/startx
> then open aterm for navigating.
>
> Thankfully it works(this people can install
> it a test it out.)

Well, it is possible that /bin/sh points to a non-bash shell but maybe 
not (I'm pretty sure the make command executes the scripts 
with /bin/sh).  Either way, I checked in the fix to the SVN tree 
earlier today so newer releases will have the fix; if needed I can 
release a 0.19.1 or similar but I want to wait and see how widespread 
the problem is ...

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin Mattock]

On Thu, Jan 15, 2009 at 2:52 PM, Paul Moore <paul.moore@hp.com> wrote:
> On Thursday 15 January 2009 5:00:55 pm Justin Mattock wrote:
>> On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <paul.moore@hp.com> wrote:
>> > On Wednesday 14 January 2009 9:43:56 pm Justin P. Mattock wrote:
>> >> Paul Moore wrote:
>> >> > On Wednesday 14 January 2009 4:35:25 pm Justin P. Mattock wrote:
>> >> >> 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
>> >> >
>> >> > Huh, can you try the following:
>> >> >
>> >> >  1. Open the netlabel_tools-0.19/Makefile in your favorite
>> >> > editor 2. Change the ". version_info; \" line to "source
>> >> > ./version_info; \" 3. Save your changes
>> >> >  4. Try running "make" again
>> >> >
>> >> > Thanks.
>> >>
>> >> O.k. changed . version like how you had posted.
>> >> The package compiled like a charm.
>> >
>> > Great, I'll change the Makefile(s) in SVN ... I don't quite
>> > understand the reason (what is your /bin/sh?  I'm guessing not
>> > bash?) but at least we now have a solution :)
>> >
>> > --
>> > paul moore
>> > linux @ hp
>>
>> hmm..
>> under ps auxZ
>> I see:
>> 2896 tty1 S+ 0:00 /bin/bash /usr/bin/startx
>> then open aterm for navigating.
>>
>> Thankfully it works(this people can install
>> it a test it out.)
>
> Well, it is possible that /bin/sh points to a non-bash shell but maybe
> not (I'm pretty sure the make command executes the scripts
> with /bin/sh).  Either way, I checked in the fix to the SVN tree
> earlier today so newer releases will have the fix; if needed I can
> release a 0.19.1 or similar but I want to wait and see how widespread
> the problem is ...
>
> --
> paul moore
> linux @ hp
>

Cool, If I see anybody
struggling, I point them to the
fix you posted.
I also might be missing something, i.g.
one of the boxes that gave this error I built
with debootstrap, but then the other that gave this as well
was built with nubuntu which seems more complete
than debootstrap.
but then maybe both are missing a package.
(or it's a debian thing)

regards;

-- 
Justin P. Mattock

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Paul Moore]

On Thursday 15 January 2009 7:44:15 pm Justin Mattock wrote:
> On Thu, Jan 15, 2009 at 2:52 PM, Paul Moore <paul.moore@hp.com> wrote:
> > Well, it is possible that /bin/sh points to a non-bash shell but
> > maybe not (I'm pretty sure the make command executes the scripts
> > with /bin/sh).  Either way, I checked in the fix to the SVN tree
> > earlier today so newer releases will have the fix; if needed I can
> > release a 0.19.1 or similar but I want to wait and see how
> > widespread the problem is ...
> >
> > --
> > paul moore
> > linux @ hp
>
> Cool, If I see anybody
> struggling, I point them to the
> fix you posted.

Great.  Also let me know, if this looks like it will be widespread 
problem I'll make a new release; I'd hate for people to have to patch 
the Makefile to get it to build ...

> I also might be missing something, i.g.
> one of the boxes that gave this error I built
> with debootstrap, but then the other that gave this as well
> was built with nubuntu which seems more complete
> than debootstrap.
> but then maybe both are missing a package.
> (or it's a debian thing)

It could also be my rather poor understanding of bash and makefiles :)  
If anyone out there wants to take a look and offer an explanation or a 
better patch I'm more than happy to accept it.

-- 
paul moore
linux @ hp

Re: netlabel: UNLABELED ath9k not denying unlabeled traffic

[Justin P. Mattock]

Paul Moore wrote:
> On Thursday 15 January 2009 7:44:15 pm Justin Mattock wrote:
>   
>> On Thu, Jan 15, 2009 at 2:52 PM, Paul Moore <paul.moore@hp.com> wrote:
>>     
>>> Well, it is possible that /bin/sh points to a non-bash shell but
>>> maybe not (I'm pretty sure the make command executes the scripts
>>> with /bin/sh).  Either way, I checked in the fix to the SVN tree
>>> earlier today so newer releases will have the fix; if needed I can
>>> release a 0.19.1 or similar but I want to wait and see how
>>> widespread the problem is ...
>>>
>>> --
>>> paul moore
>>> linux @ hp
>>>       
>> Cool, If I see anybody
>> struggling, I point them to the
>> fix you posted.
>>     
>
> Great.  Also let me know, if this looks like it will be widespread 
> problem I'll make a new release; I'd hate for people to have to patch 
> the Makefile to get it to build ...
>
>   
no problem.
>> I also might be missing something, i.g.
>> one of the boxes that gave this error I built
>> with debootstrap, but then the other that gave this as well
>> was built with nubuntu which seems more complete
>> than debootstrap.
>> but then maybe both are missing a package.
>> (or it's a debian thing)
>>     
>
> It could also be my rather poor understanding of bash and makefiles :)  
> If anyone out there wants to take a look and offer an explanation or a 
> better patch I'm more than happy to accept it.
>
>   
here as well.

regards;

Justin P. Mattock