RE: [PATCH 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
> From: Venkat Yekkirala [mailto:[EMAIL PROTECTED]
>
> > 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.
>
> >
> > audit(1163061323.188:197): avc: denied { send } for pid=1676
> > comm="modprobe" daddr=ff02:::::::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::::020c:29ff:fe72:2dd1
> > src=5353 daddr=ff02:::::::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::::020c:29ff:fe72:2dd1
> > src=5353 daddr=ff02:::::::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::::020c:29ff:fe72:2dd1
> > daddr=ff02:::::::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..
>
> 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..
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
Venkat Yekkirala wrote:
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:::::::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::::020c:29ff:fe72:2dd1
src=5353 daddr=ff02:::::::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::::020c:29ff:fe72:2dd1
src=5353 daddr=ff02:::::::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::::020c:29ff:fe72:2dd1
daddr=ff02:::::::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?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
> > Venkat Yekkirala wrote:
> > >
> > > +
> > > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > > + PACKET__FLOW_IN, NULL);
> > > + if (err)
> > > + goto out;
> > > +
> > > + if (xfrm_sid) {
> > > + err = security_transition_sid(xfrm_sid, skb->secmark,
> > > + SECCLASS_PACKET, &trans_sid);
> > > + if (err)
> > > + goto out;
> > > +
> > >
> > I thought we weren't doing transitions to label packets anymore per the
> > conference call?
>
> No, transitions are still part of the reconciliation process. By
> default, this just means that we end up with the xfrm_sid (which is what
> you want). But it allows us the freedom to define transitions on the
> secmark label if desired, and those transitions can still yield subject
> labels.
>
This is not consistent with my perception of the decision made in the
conference call. I thought that the secid was either going to be 1) the
secmark label if no external labeling is present or 2) the external
label if it is present. The flow_in permission would be checked between
the external label and the secmark label in either case (unlabeled in
the case of #1)
How is this different from the implementation before the call?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
Venkat Yekkirala wrote:
+
+ err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb->secmark,
+ SECCLASS_PACKET, &trans_sid);
+ if (err)
+ goto out;
+
I thought we weren't doing transitions to label packets anymore per the
conference call?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SECMARK 1.0
James Morris wrote:
For example, SELinux will now be able to utilize connection tracking, so
that only packets which are known to be valid for a specific connection
will be allowed to reach the subject.
Sample iptables rules for labeling packets are at:
http://people.redhat.com/jmorris/selinux/secmark/rules/
And examples of new policy controls may be found here:
http://people.redhat.com/jmorris/selinux/secmark/policy/
It looks like you are labeling all packets on an established connection
as tracked_packet_t. What is the rationale for not labeling all ftp
traffic as ftpd_packet_t? Granted that its very unlikely for established
connections to go to the wrong process but the SELinux policy should be
able to clearly show that ftpd and sshd cannot see each others packets
but these policies say that they can both send/receive tracked_packet_t.
Obviously these are just examples, I'm just curious if there was a
reason to label established packets differently from the new connection
packets (and the same as all the other established packets)
I imagine that, at least at first, it would be good to have allow domain
unlabeled_t:packet { send recv }; in an (enabled) conditional so that
the migration will be easier.
Also, we need to come up with a mechanism for distributing default
marking rules that can accompany a policy. The rules could go into a
section in the .pp file but how does that integrate with various
firewall systems that take control of the iptables rules?
And finally, what happens if the labeling rule changes during an
established connection? Do the packets related to that connection retain
the original label or will they get the new label?
Thanks, this will be very beneficial to the SELinux community
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
