secmark=XXX mapping

[Mr Dash Four]

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