>>> One item to note: xt_SECMARK.c is presently using selinux-specific >>> interfaces for mapping the security context string to a sid originally, >>> as well as to check permissions, manage refcounts, etc. So if you use >>> the LSM hooks for mapping the secid back to a context, there will be an >>> inconsistency in the interface. Likely they should all be LSM hooks and >>> both include/linux/selinux.h and security/selinux/exports.c should go >>> away. >>> >>> >> I found a way to alter the iptables source to get that information - see my >> own thread on the netfilter mailing list here - >> http://www.spinics.net/lists/netfilter/msg49094.html >> >> Whether the devs responsible for iptables/netfilter would agree to make >> these changes I am not sure - I patched my own iptables and it works! >> > > 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. > I'm not on netfilter list so I can't just in, but if you cc me on a > response to that thread I'll start responding there (hopefully soon > with a patch) > I'll quote the above as a separate post and will cc you in - no problem. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
