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
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
([email protected]) 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
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
> ([email protected]) 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
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
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
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
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
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
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
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
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
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
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
On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <[email protected]> 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
On Thursday 15 January 2009 5:00:55 pm Justin Mattock wrote:
> On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <[email protected]> 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
On Thu, Jan 15, 2009 at 2:52 PM, Paul Moore <[email protected]> wrote:
> On Thursday 15 January 2009 5:00:55 pm Justin Mattock wrote:
>> On Thu, Jan 15, 2009 at 9:46 AM, Paul Moore <[email protected]> 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
On Thursday 15 January 2009 7:44:15 pm Justin Mattock wrote:
> On Thu, Jan 15, 2009 at 2:52 PM, Paul Moore <[email protected]> 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
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 <[email protected]> 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