On Tue, Sep 21, 2010 at 4:26 PM, Eric Paris <eparis@xxxxxxxxxxxxxx> wrote: > On Tue, Sep 21, 2010 at 4:13 PM, Mr Dash Four > <mr.dash.four@xxxxxxxxxxxxxx> wrote: >> >>>> http://www.spinics.net/lists/netfilter/msg49106.html >>>> >>>> I don't think that approach is right. Exporting a number at ALL is >>>> broken. It should only ever say the name. >>>> >>> >>> I am aware of that and the proposed patch works as I did test it after Tom >>> released it yesterday. >>> >>> As for your comment above - it is better than NOTHING. >>> >>> If you think that the current scenario, when I see meaningless number in >>> the secmark field, helps me track the actual security context of the listed >>> connection, then think again, because there is NO way I could know what >>> number maps to which context. >>> >>> Tom's patch at least gives me that mapping when I list the mangle table, >>> so it is a start and it works. Again, - the patch, if applied, is better >>> than what currently exists in iptables. Also, 'exporting a number at all' is >>> NOT broken - look at Tom's patch again - it does not break anything. > > No disagreement that Tom's patch is better than what we have today, I > just claim that what we have today is completely wrong, so this is > only slightly better :) > > sids, secids, secmarks, or whatever you want to call that u32 is just > a dynamically generated number which should only exist inside the > kernel and should never be shown to userspace. Loading secmark rules > uses a full context string and then uses that string to generate a u32 > which the kernel can efficiently use. When we display things back to > userspace we should always be converting that u32 back to a string. > I'm working on a patch to do this (actually it's compiling while I > type) My current patch looks like so: cat /proc/net/nfs_conntrack ipv4 2 udp 17 8 src=10.11.231.82 dst=10.11.255.156 sport=34095 dport=53 src=10.11.255.156 dst=10.11.231.82 sport=53 dport=34095 mark=0 secmark=system_u:object_r:unlabeled_t:s0 use=2 ipv4 2 tcp 6 114 TIME_WAIT src=10.11.231.82 dst=10.5.30.68 sport=49241 dport=80 src=10.5.30.68 dst=10.11.231.82 sport=80 dport=49241 [ASSURED] mark=0 secmark=system_u:object_r:compartment_packet_t:s0:c100 use=2 Does anyone feel like this is going to break some userspace compatibility to send the string? The number is useless and obviously noone could have been doing anything with it (as Mr Dash Four realized). It shouldn't have ever been sent to start with but it has been there a long time (7c9728c3). Anyone have thoughts? It appears that we send this information up some netlink socket in nf_conntrack_netlink.c. I'm not sure what is consuming this data so I'm not sure how to test. Anyone have any pointers? I'm also worried what such a change will do to users of this interface.... -Eric -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
