>> 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.