network and module problems

network and module problems

[Timothy Wood]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Hello all,

I installed the full lsm package onto a RH7.2 machine and I'm seeing
problems when I try to insmod a module or to get any type of networking
loaded.  

Network first.  When the machine boots no network interfaces are loaded,
not even the loopback.  If I try to run `ifup lo` or something similar
to raise the interface I get the error:

Cannot send dump request: Connection refused

I know this isn't just a problem with the network driver since the
loopback doesn't raise either, but I have tried loading my nic as a
module and by building it straight into the kernel.  Which brings me to
the module problem.  Dmesg shows that it finds the nic but I never see
the module as being loaded when I run lsmod and when I try to insmod it
I get an error saying that it can't locate the card on the console and
avc errors in the system log.

I'm also running this on ext3 if that might have something to do with it
since I know ext3 isn't properly supported yet.  Anyhow, any ideas are
welcome and I can reload this machine if the need arises.  Thanks.

Timothy,


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: network and module problems

[Stephen Smalley]

On 24 Jan 2002, Timothy Wood wrote:

> Cannot send dump request: Connection refused

Did you enable Netlink support when you configured the kernel?
What release of SELinux are you using?

> module and by building it straight into the kernel.  Which brings me to
> the module problem.  Dmesg shows that it finds the nic but I never see
> the module as being loaded when I run lsmod and when I try to insmod it
> I get an error saying that it can't locate the card on the console and
> avc errors in the system log.

If you build the module into the kernel, it won't show up in lsmod.
What AVC errors are being logged?  Did you run insmod after logging
into the sysadm_r role?  Also, is your kernel in permissive mode or
enforcing mode?

> I'm also running this on ext3 if that might have something to do with it
> since I know ext3 isn't properly supported yet.  Anyhow, any ideas are
> welcome and I can reload this machine if the need arises.  Thanks.

ext3 works fine.  It was only an issue when ext3 support wasn't in the
mainstream kernel.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Timothy Wood]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

On Thu, 2002-01-24 at 13:58, Stephen Smalley wrote:
> 
> On 24 Jan 2002, Timothy Wood wrote:
> 
> > Cannot send dump request: Connection refused
> 
> Did you enable Netlink support when you configured the kernel?
> What release of SELinux are you using?

Yes. 2001121010 (according to the tarball)

> 
> > module and by building it straight into the kernel.  Which brings me to
> > the module problem.  Dmesg shows that it finds the nic but I never see
> > the module as being loaded when I run lsmod and when I try to insmod it
> > I get an error saying that it can't locate the card on the console and
> > avc errors in the system log.
> 
> If you build the module into the kernel, it won't show up in lsmod.
> What AVC errors are being logged?  Did you run insmod after logging
> into the sysadm_r role?  Also, is your kernel in permissive mode or
> enforcing mode?

I realise that.  I merely brought it up in regards to the time when the
network was built as a module.  

kernel: avc: denied { read } for pid=268 exe=/sbin/insmod
path=/etc/modules.conf.vm dev=08:01 ino=213709
scontext=system-U:system_r:kmod_t
tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

that is one of the errors.  if you want an entire boot log I can provide
that.  Yes I did try insmoding after I logged in as an administrator and
thats when the I get the error telling me that it can't locate the card
despite the fact that dmesg shows it was found during boot.  I really
don't think this is a problem the network driver as the loopback (lo)
interface is never raised either.  The dump request thing looks like the
root of the problem since it occurs if I try to raise either the eth0 or
lo interfaces.  The system boots into permissive mode and I usually
leave it there.

> 
> > I'm also running this on ext3 if that might have something to do with it
> > since I know ext3 isn't properly supported yet.  Anyhow, any ideas are
> > welcome and I can reload this machine if the need arises.  Thanks.
> 
> ext3 works fine.  It was only an issue when ext3 support wasn't in the
> mainstream kernel.

Ah, I see.  Thanks for the clarification.

Timothy,

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: network and module problems

[Stephen Smalley]

On 25 Jan 2002, Timothy Wood wrote:

> > Did you enable Netlink support when you configured the kernel?
> > What release of SELinux are you using?
>
> Yes. 2001121010 (according to the tarball)

Make sure that you enabled both Netlink and its associated Routing
messages options.  These options are needed by the RH7.2 utilities, but
were not needed on RH7.1.

Also, be aware that you are using an older release - the current release
is 2002011718.  I would recommend upgrading to the current release.

> The system boots into permissive mode and I usually leave it there.

Ok, so this means that SELinux isn't preventing anything from happening.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Paul Krumviede]

--On Friday, 25 January, 2002 09:36 -0500 Timothy Wood 
<timothy@hallcomp.com> wrote:

> On Thu, 2002-01-24 at 13:58, Stephen Smalley wrote:
>>
>> > module and by building it straight into the kernel.  Which brings me to
>> > the module problem.  Dmesg shows that it finds the nic but I never see
>> > the module as being loaded when I run lsmod and when I try to insmod it
>> > I get an error saying that it can't locate the card on the console and
>> > avc errors in the system log.
>>
>> If you build the module into the kernel, it won't show up in lsmod.
>> What AVC errors are being logged?  Did you run insmod after logging
>> into the sysadm_r role?  Also, is your kernel in permissive mode or
>> enforcing mode?
>
> I realise that.  I merely brought it up in regards to the time when the
> network was built as a module.
>
> kernel: avc: denied { read } for pid=268 exe=/sbin/insmod
> path=/etc/modules.conf.vm dev=08:01 ino=213709
> scontext=system-U:system_r:kmod_t
> tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

are you running this inside a VMware virtual machine? i had to create
a policy file for that environment (which is yet to be tested with the
latest release; i'll send it to the list once that happens). the VMware
dualconf script instantiates /etc/modules.conf (and some other
files for X11) as a symlink to the appropriate "real" file depending
on whether one boots the guest OS as a virtual machine or on the
real hardware.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Timothy Wood]

[-- Attachment #1: Type: text/plain, Size: 5135 bytes --]

On Fri, 2002-01-25 at 10:03, Paul Krumviede wrote:
> --On Friday, 25 January, 2002 09:36 -0500 Timothy Wood 
> <timothy@hallcomp.com> wrote:
> 
> are you running this inside a VMware virtual machine? i had to create
> a policy file for that environment (which is yet to be tested with the
> latest release; i'll send it to the list once that happens). the VMware
> dualconf script instantiates /etc/modules.conf (and some other
> files for X11) as a symlink to the appropriate "real" file depending
> on whether one boots the guest OS as a virtual machine or on the
> real hardware.
> 
> -paul

Yes, I am running it in a VM.  I just looked at the context of the
modules files in /etc and noticed they were different, probably because
I installed the VMware tools after I relabled the files.  I did a make
relabel and I can insmod things now but the lo and eth0 interfaces still
never raise.  What I still don't see is how the lo interface never loads
because as far as I know the lo interface doesn't have a module.  I'm
sifting through dmesg once again, a little more closely this time, and
I"m seeing a lot of wierd things.  Someone tell me if all this looks
right.

(right after journalled loads)
kernel: There is already a security framework initialized,
register_security failed.
kernel: Failure registering capabilities with the kernel
kernel: selinux_register_security:  Registering secondary module
capability
localhost kernel: Capability LSM initialized

...

kernel: pcnet32_probe_pci: found device 0x001022.0x002000
kernel: PCI: Enabling device 00:11.0 (0001 -> 0003)
kernel: PCI: Assigned IRQ 10 for device 00:11.0
keytable: Loading system font: succeeded
kernel: ioaddr=0x001080 resource_flags=0x000101
kernel: eth0: PCnet/PCI II 79C970A at 0x1080, 00 50 56 4a 80 ad
kernel: pcnet32: pcnet32_private lp=c1151000 lp_dma_addr=0x1151000
assigned IRQ 10
kernel: pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.de

...

kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 1 exe=none
kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 1 exe=none

...

kernel: avc:  denied  { read } for  pid=74 exe=/sbin/insmod
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:insmod_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file
kernel:
kernel: avc:  denied  { read } for  pid=108 exe=/sbin/depmod
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:depmod_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file
kernel:
kernel: avc:  denied  { read } for  pid=110 exe=/bin/grep
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file
kernel: task_precondition:  assigning context system_u:system_r:init_t
to pid 2 exe=none
kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 3 exe=none
kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 4 exe=none
kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 5 exe=none
kernel: task_precondition:  assigning context system_u:system_r:kernel_t
to pid 6 exe=none
kernel: task_precondition:  assigning context system_u:system_r:init_t
to pid 7 exe=none

...

kernel: avc:  denied  { read } for  pid=220 exe=/usr/sbin/updfstab
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

...

kernel: avc:  denied  { read } for  pid=220 exe=/usr/sbin/updfstab
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

...

kernel: avc:  denied  { unlink } for  pid=251 exe=/bin/rm
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

...

kernel: avc:  denied  { unlink } for  pid=253 exe=/bin/rm
path=/etc/X11/X dev=08:01 ino=102038 scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:etc_t tclass=lnk_file

...

kernel: avc:  denied  { read } for  pid=268 exe=/sbin/insmod
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:kmod_t
tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

...

kernel: avc:  denied  { read } for  pid=329 exe=/sbin/insmod
path=/etc/modules.conf dev=08:01 ino=213709
scontext=system_u:system_r:insmod_t
tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

...

network: Setting network parameters:  succeeded 
ifup: Cannot send dump request: Connection refused 

now I tried doing a tail -f on /var/log/messages and then switching to
another VT to raise both the lo and eth0 interfaces and nothing was
logged but I still get that dump request refused message.  Could the
selinux be blocking the device from being opened or something?

I'm going to download this new version, but should I just get the patch
and apply it to the current version I have or what?

Timothy,


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: network and module problems

[Paul Krumviede]

--On Friday, 25 January, 2002 11:35 -0500 Timothy Wood 
<timothy@hallcomp.com> wrote:

> On Fri, 2002-01-25 at 10:03, Paul Krumviede wrote:
>> --On Friday, 25 January, 2002 09:36 -0500 Timothy Wood
>> <timothy@hallcomp.com> wrote:
>>
>> are you running this inside a VMware virtual machine? i had to create
>> a policy file for that environment (which is yet to be tested with the
>> latest release; i'll send it to the list once that happens). the VMware
>> dualconf script instantiates /etc/modules.conf (and some other
>> files for X11) as a symlink to the appropriate "real" file depending
>> on whether one boots the guest OS as a virtual machine or on the
>> real hardware.
>>
>> -paul
>
> Yes, I am running it in a VM.  I just looked at the context of the
> modules files in /etc and noticed they were different, probably because
> I installed the VMware tools after I relabled the files.

the VMware dualconf init script creates symlinks during the bootup,
so until i (or someone else) puts it into its own domain, the symlinks
get labelled with the etc_runtime_t type. this will happen every time
at boot; relabeling by running setfiles doesn't seem like a good solution.
installing the VMware tools creates /etc/modules.conf.{vm, org} and
these should be labelled with the modules_conf_t type.

> I did a make
> relabel and I can insmod things now but the lo and eth0 interfaces still
> never raise.  What I still don't see is how the lo interface never loads
> because as far as I know the lo interface doesn't have a module.  I'm
> sifting through dmesg once again, a little more closely this time, and
> I"m seeing a lot of wierd things.  Someone tell me if all this looks
> right.
>
> (right after journalled loads)
> kernel: There is already a security framework initialized,
> register_security failed.
> kernel: Failure registering capabilities with the kernel
> kernel: selinux_register_security:  Registering secondary module
> capability
> localhost kernel: Capability LSM initialized

i see this on correctly running systems... but i have wondered about
the failure message.

> kernel: pcnet32_probe_pci: found device 0x001022.0x002000
> kernel: PCI: Enabling device 00:11.0 (0001 -> 0003)
> kernel: PCI: Assigned IRQ 10 for device 00:11.0
> keytable: Loading system font: succeeded
> kernel: ioaddr=0x001080 resource_flags=0x000101
> kernel: eth0: PCnet/PCI II 79C970A at 0x1080, 00 50 56 4a 80 ad
> kernel: pcnet32: pcnet32_private lp=c1151000 lp_dma_addr=0x1151000
> assigned IRQ 10
> kernel: pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.de

looks normal.

> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 1 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 1 exe=none

looks normal.

> kernel: avc:  denied  { read } for  pid=74 exe=/sbin/insmod
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:insmod_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

this is what i would expect to see as one reboots a virtual
machine after relabelling (dualconf hasn't run yet, so the
symbolic link hasn't been newly created and thus has the
previous label).

> kernel:
> kernel: avc:  denied  { read } for  pid=108 exe=/sbin/depmod
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:depmod_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file
> kernel:
> kernel: avc:  denied  { read } for  pid=110 exe=/bin/grep
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

and all of these are, i think, artifacts of the VMware dualconf
construct.

> kernel: task_precondition:  assigning context system_u:system_r:init_t
> to pid 2 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 3 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 4 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 5 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 6 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:init_t
> to pid 7 exe=none

these look normal.

> kernel: avc:  denied  { read } for  pid=220 exe=/usr/sbin/updfstab
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:fsadm_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

> kernel: avc:  denied  { read } for  pid=220 exe=/usr/sbin/updfstab
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:fsadm_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

> kernel: avc:  denied  { unlink } for  pid=251 exe=/bin/rm
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

> kernel: avc:  denied  { unlink } for  pid=253 exe=/bin/rm
> path=/etc/X11/X dev=08:01 ino=102038 scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:etc_t tclass=lnk_file

more artifacts of VMware...

> kernel: avc:  denied  { read } for  pid=268 exe=/sbin/insmod
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:kmod_t
> tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

the dualconf script has run, so /etc/modules.conf was
created anew, and thus has the etc_runtime_t type. this
and the following message are thus also VMware related.

> kernel: avc:  denied  { read } for  pid=329 exe=/sbin/insmod
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:insmod_t
> tcontext=system_u:object_r:etc_runtime_t tclass=lnk_file

> network: Setting network parameters:  succeeded
> ifup: Cannot send dump request: Connection refused

> now I tried doing a tail -f on /var/log/messages and then switching to
> another VT to raise both the lo and eth0 interfaces and nothing was
> logged but I still get that dump request refused message.  Could the
> selinux be blocking the device from being opened or something?

not if you are running in permissive mode.

> I'm going to download this new version, but should I just get the patch
> and apply it to the current version I have or what?

i'd suggest getting a working kernel with your current selinux
version. if all else fails, i can probably send you a .config file
from a running redhat 7.2 system that does run in a VMware
virtual machine.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Stephen Smalley]

On 25 Jan 2002, Timothy Wood wrote:

> never raise.  What I still don't see is how the lo interface never loads
> because as far as I know the lo interface doesn't have a module.  I'm
> sifting through dmesg once again, a little more closely this time, and
> I"m seeing a lot of wierd things.  Someone tell me if all this looks
> right.

I've seen the error that you are seeing before, but it was due to not
enabling the Netlink and Routing message options in the kernel config for
RH7.2 systems.  It didn't have anything to do with SELinux.  If you are
running in permissive mode, then SELinux won't deny anything, so the avc
denied messages are irrelevant, although you will need to customize the
policy for your VMware setup before switching into enforcing mode.

> (right after journalled loads)
> kernel: There is already a security framework initialized,
> register_security failed.
> kernel: Failure registering capabilities with the kernel
> kernel: selinux_register_security:  Registering secondary module
> capability
> localhost kernel: Capability LSM initialized

These messages are normal.  The capabilities security module tries to
register itself as the primary security module and fails (because SELinux
has already registered itself), and then falls back to registering itself
as a secondary security module (under the SELinux module).

> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 1 exe=none
> kernel: task_precondition:  assigning context system_u:system_r:kernel_t
> to pid 1 exe=none

These messages are normal.  They occur when SELinux encounters a process
that was created before SELinux loaded the policy configuration, and
simply show that SELinux is assigning a security context to the
pre-existing process based on the policy.

> kernel: avc:  denied  { read } for  pid=74 exe=/sbin/insmod
> path=/etc/modules.conf dev=08:01 ino=213709
> scontext=system_u:system_r:insmod_t
> tcontext=system_u:object_r:modules_conf_t tclass=lnk_file

The avc denied messages reflect aspects of your VMWare setup.
You'll need to grant these permissions before switching into enforcing
mode, but they are irrelevant while in permissive mode.

> network: Setting network parameters:  succeeded
> ifup: Cannot send dump request: Connection refused

As I said, I've only see this occur when Netlink and Routing message
support is not enabled in the kernel config.

> I'm going to download this new version, but should I just get the patch
> and apply it to the current version I have or what?

There have been a number of bug fixes (patches posted to the mailing list)
since the old release, as well as some minor enhancements and upgrades to
the base kernel versions (available in the new release).

If you want to more easily track new versions, you might want to checkout
the CVS tree at the sourceforge site.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Stephen Smalley]

On Fri, 25 Jan 2002, Stephen Smalley wrote:

> If you want to more easily track new versions, you might want to checkout
> the CVS tree at the sourceforge site.

Just to clarify, the directories under 'nsa' in the CVS tree are the ones
you want - they track the NSA distribution.  The top-level 'selinux'
directory contains the original SELinux prototype and is obsolete.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Paul Krumviede]

--On Friday, 25 January, 2002 12:47 -0500 Stephen Smalley <sds@tislabs.com> 
wrote:

>
> On 25 Jan 2002, Timothy Wood wrote:
>
>> never raise.  What I still don't see is how the lo interface never loads
>> because as far as I know the lo interface doesn't have a module.  I'm
>> sifting through dmesg once again, a little more closely this time, and
>> I"m seeing a lot of wierd things.  Someone tell me if all this looks
>> right.
>
> I've seen the error that you are seeing before, but it was due to not
> enabling the Netlink and Routing message options in the kernel config for
> RH7.2 systems.

is this true for both 2.4.16 and 2.4.17 kernels? i just looked at my RH7.2
system, and the kernel config file for the 2.4.16 build has CONFIG_NETLINK,
CONFIG_RTNETLINK and CONFIG_NETLINK_DEV, while the 2.4.17
kernel only has CONFIG_NETLINK_DEV (and Documentation/Configure.help
implies that the other 2 are only for 2.5 kernels)...

so maybe going to the new release would have avoided this confusion
after all.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Timothy Wood]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

This is just a real quick post before I have to run out of the office. 
I switched to enforcing mode and tried bringing up the interface and
this is what I got.

kernel: avc: denied { create } for pid=761 exe=/sbin/ip
scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t
tclass=netlink_socket

I'll check out that posted VMware Rules as soon as I get the chance and
then try the new version.

Timothy,

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: network and module problems

[Stephen Smalley]

On Fri, 25 Jan 2002, Paul Krumviede wrote:

> is this true for both 2.4.16 and 2.4.17 kernels? i just looked at my RH7.2
> system, and the kernel config file for the 2.4.16 build has CONFIG_NETLINK,
> CONFIG_RTNETLINK and CONFIG_NETLINK_DEV, while the 2.4.17
> kernel only has CONFIG_NETLINK_DEV (and Documentation/Configure.help
> implies that the other 2 are only for 2.5 kernels)...
>
> so maybe going to the new release would have avoided this confusion
> after all.

I think that the two "basic" netlink options were mainstreamed in 2.4.17.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Stephen Smalley]

On 25 Jan 2002, Timothy Wood wrote:

> kernel: avc: denied { create } for pid=761 exe=/sbin/ip
> scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t
> tclass=netlink_socket

Yes, at present, there isn't a domain transition from sysadm_t to
netutils_t, so this isn't surprising.  But this wouldn't occur when run
by the rc scripts, and it doesn't explain why you would have a problem
when in permissive mode.   I still think you have a bad kernel
configuration (missing one or both of the Netlink or Routing messages
options).

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: network and module problems

[Timothy Wood]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Fri, 2002-01-25 at 14:04, Stephen Smalley wrote:
>I still think you have a bad kernel
> configuration (missing one or both of the Netlink or Routing messages
> options).
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com

Question.  I noticed you said "routing messages".  Ok, two questions
really.  First off what does routing messages have to do with raising
the interface?  Secondly, why is the routing messages not mentioned in
the install readme?  Because the install mentions netlink, which I
kindly made certain was built into the kernel and why I so greatly
protested that I was not stupid enough to have missed something in the
readme I so carefully followed to the letter.  Also, you mentioned there
was a new version of the lsm out and I just downloaded the one I have
now only like a week ago.  So am I going to the wrong place for all this
stuff or what?  The NSA site is the right place correct?

At any rate it IS working now and I feel terrible that I wasted
everyone's time.  I would like to suggest that the install readme be
updated though and I would be happy to do it if someone would tell me
where I can submit the change.  Thanks again everyone.

Timothy,

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: network and module problems

[Stephen Smalley]

On 25 Jan 2002, Timothy Wood wrote:

> Question.  I noticed you said "routing messages".  Ok, two questions
> really.  First off what does routing messages have to do with raising
> the interface?

The option listed as "Routing messages", aka CONFIG_RTNETLINK, allows user
space programs to receive routing information over netlink sockets.  The
RH7.2 networking utilities expect this support to be present.  I don't
know why they can't gracefully recover when it isn't available.

>Secondly, why is the routing messages not mentioned in
> the install readme?  Because the install mentions netlink, which I
> kindly made certain was built into the kernel and why I so greatly
> protested that I was not stupid enough to have missed something in the
> readme I so carefully followed to the letter.

It was an oversight in the README that was in the 12/10/2001 release,
and was fixed in the README before the 1/18/2002 release.  Of course, it
is now irrelevant for the 2.4-based SELinux because the two netlink
options have been mainstreamed in 2.4.17.

>Also, you mentioned there
> was a new version of the lsm out and I just downloaded the one I have
> now only like a week ago.  So am I going to the wrong place for all this
> stuff or what?  The NSA site is the right place correct?

The NSA SELinux web site was updated on 1/18/2002.  So if you downloaded
the release prior to that date, you would have obtained the prior release,
which was made on 12/10/2001.  Yes, the NSA web site is the right place,
but new releases have been relatively frequent to track new kernel
versions and other developments.

> At any rate it IS working now and I feel terrible that I wasted
> everyone's time.  I would like to suggest that the install readme be
> updated though and I would be happy to do it if someone would tell me
> where I can submit the change.  Thanks again everyone.

It was already fixed.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.