labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]

PATCH In review Venkat Yekkirala 4 participants 7 messages Nov 8, 2006 – Nov 13, 2006

Subsystems (3)

Networking Network drivers SELinux security module

lore

Share & tools

lore

Venkat Yekkirala

author

2006-11-08 23:03 UTC #0 lore raw

cover labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]

This patchset is against davem's net-2.6.git. Please apply to 2.6.19.

The following are the changes since the previous post of this patchset:

1. Separate BUG_ON usage per Eric's suggestion.

2. Replace security_sid_compare with a simple sid compare check per a suggestion from Paul/Stephen.

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.

James Morris

2006-11-09 06:29 UTC #1 lore raw

Quoted 8 lines · Venkat Yekkirala

This patchset is against davem's net-2.6.git. Please apply to 2.6.19.
The following are the changes since the previous post of this patchset:
1. Separate BUG_ON usage per Eric's suggestion.
2. Replace security_sid_compare with a simple sid compare check per a suggestion from Paul/Stephen.

Applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.20.git

I think this should be aimed at 2.6.20, because we are at the last or second-last -rc currently, and I don't think these fixes are urgent enough to justify the risk at this stage. Also, I think this code needs more testing, and more general progress towards code completion.

- James

Signature · 7 lines

James Morris
<[email protected]>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

David Miller

maintainer

2006-11-09 06:42 UTC #2 lore raw

From: James Morris <[email protected]>
Date: Thu, 9 Nov 2006 01:30:05 -0500 (EST)

Quoted 4 lines

I think this should be aimed at 2.6.20, because we are at the last or second-last -rc currently, and I don't think these fixes are urgent enough to justify the risk at this stage. Also, I think this code needs more testing, and more general progress towards code completion.

This is the way I feel too.

Venkat Yekkirala

author

2006-11-09 14:14 UTC #3 lore raw

In reply to James Morris

Quoted 4 lines

I think this should be aimed at 2.6.20, because we are at the last or second-last -rc currently, and I don't think these fixes are urgent enough
to justify the risk at this stage.

That makes sense. Thanks.

Joshua Brindle

2006-11-11 16:22 UTC #4 lore raw

In reply to Venkat Yekkirala

Quoted 9 lines · Venkat Yekkirala

This patchset is against davem's net-2.6.git. Please apply to 2.6.19.
The following are the changes since the previous post of this patchset:
1. Separate BUG_ON usage per Eric's suggestion.
2. Replace security_sid_compare with a simple sid compare check per a suggestion from Paul/Stephen.

I pulled in the lspp respin kernels and am checking the labeling behavior now so I should have a full response later, however I ran into one unexpected thing immediately on bootup with the new kernel:

audit(1163061323.188:197): avc:  denied  { send } for  pid=1676 comm="modprobe" daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
audit(1163061343.335:204): avc:  denied  { send } for  pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
audit(1163061343.338:205): avc:  denied  { recv } for  pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
audit(1163061346.139:210): avc:  denied  { send } for  pid=1856 comm="smartd-conf.py" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet

These denials come after iptables-restore sets up labeling in the mangle table so I'm not sure why they are unlabeled.. They also don't say which port they were using, perhaps is it a different protocol that our packet labeling isn't covering yet? Is there any way we could get protocol information in the denial?

Venkat Yekkirala

author

2006-11-13 15:42 UTC #5 lore raw

Quoted 4 lines

I pulled in the lspp respin kernels and am checking the labeling behavior now so I should have a full response later, however I ran into
one unexpected thing immediately on bootup with the new kernel:

Just FYI- The labeled-ipsec patch doesn't affect or influence the packet class handling in any manner.

Quoted 22 lines

audit(1163061323.188:197): avc: denied { send } for pid=1676 comm="modprobe" daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061343.335:204): avc: denied { send } for pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061343.338:205): avc: denied { recv } for pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061346.139:210): avc: denied { send } for pid=1856 comm="smartd-conf.py" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet

Quoted 3 lines

These denials come after iptables-restore sets up labeling in the mangle
table so I'm not sure why they are unlabeled..

Could you list the mangle table rules and see that the above IPv6 addresses are covered (i.e. labeled appropriately) or otherwise that your policy allows kernel_t to receive all packets (may or may not be desired/good, just thinking out loud).

Quoted 3 lines

They also
don't say which
port they were using,

The port info is currently available only for tcp/udp packets.

Quoted 3 lines

perhaps is it a different protocol that
our packet
labeling isn't covering yet?

James can perhaps comment on this better, but it *should* be covered to the extent that you are able to define mangle table/secmark rules for them.

Quoted 2 lines

Is there any way we could get protocol
information in the denial?

This is possible with kernel changes, specifically by adding protocol to avc_audit_data. If Stephen agrees I can look into doing it.

Joshua Brindle

2006-11-13 17:45 UTC #6 lore raw

Quoted 31 lines

From: Venkat Yekkirala [mailto:[email protected]]
Quoted 3 lines
I pulled in the lspp respin kernels and am checking the labeling behavior now so I should have a full response later, however I ran into one unexpected thing immediately on bootup with the new kernel:
Just FYI- The labeled-ipsec patch doesn't affect or influence the packet class handling in any manner.
Quoted 22 lines
audit(1163061323.188:197): avc: denied { send } for pid=1676 comm="modprobe" daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061343.335:204): avc: denied { send } for pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061343.338:205): avc: denied { recv } for pid=1804 comm="avahi-daemon" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 src=5353 daddr=ff02:0000:0000:0000:0000:0000:0000:00fb dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet audit(1163061346.139:210): avc: denied { send } for pid=1856 comm="smartd-conf.py" saddr=fe80:0000:0000:0000:020c:29ff:fe72:2dd1 daddr=ff02:0000:0000:0000:0000:0000:0000:0016 netif=eth0 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet

Quoted 8 lines

Quoted 2 lines
These denials come after iptables-restore sets up labeling in the mangle table so I'm not sure why they are unlabeled..
Could you list the mangle table rules and see that the above IPv6 addresses are covered (i.e. labeled appropriately) or otherwise that your policy allows kernel_t to receive all packets (may or may not be desired/good, just thinking out loud).

Oops, I don't have ipv6 rules (refpolicy doesn't generate them). I'm not even sure why it was on since I don't use ipv6 at all..