decipher the secmark number from nf_conntrack/ip_conntrack

DISCUSSION Mr Dash Four 4 participants 45 messages Sep 19, 2010 – Sep 24, 2010

Share & tools

Mr Dash Four

author

2010-09-19 23:04 UTC #0 lore raw

When I list my connections with 'cat /proc/net/nf_conntrack' I get the SELinux context secmark as a number, like secmark=XXX.

Is there a way I could map that number to the name of the actual context when I set it up originally with the --selctx option in iptables? If that is not possible do you plan to include such feature in the upcoming versions of netfilter?

Jan Engelhardt

2010-09-20 00:48 UTC #1 lore raw

Quoted 7 lines · Mr Dash Four

When I list my connections with 'cat /proc/net/nf_conntrack' I get the SELinux context secmark as a number, like secmark=XXX.
Is there a way I could map that number to the name of the actual context when I set it up originally with the --selctx option in iptables? If that is not possible do you plan to include such feature in the upcoming versions of netfilter?

Apart from SMACK, I don't think the kernel has knowledge about any names of sorts, especially since SELinux labels seem to be able to be longer than 8 chars.

So if anything, it would be done so in conntrack-tools which you should be using over /proc anyway.

Mr Dash Four

author

2010-09-20 10:41 UTC #2 lore raw

Quoted 10 lines

Quoted 9 lines
When I list my connections with 'cat /proc/net/nf_conntrack' I get the SELinux context secmark as a number, like secmark=XXX.
Is there a way I could map that number to the name of the actual context when I set it up originally with the --selctx option in iptables? If that is not possible do you plan to include such feature in the upcoming versions of netfilter?

Quoted 4 lines

Apart from SMACK, I don't think the kernel has knowledge about any names of sorts, especially since SELinux labels seem to be able to be longer than 8 chars.
So if anything, it would be done so in conntrack-tools which you should be using over /proc anyway.

Is there any way I could do this with conntrack-tools? The only option I could see on conntrack (the executable) is by using a filter and specifying -c or --secmark (a number) which isn't what I am after!

Jan Engelhardt

2010-09-20 12:23 UTC #3 lore raw

Quoted 14 lines · Mr Dash Four

Quoted 14 lines
Quoted 9 lines
When I list my connections with 'cat /proc/net/nf_conntrack' I get the SELinux context secmark as a number, like secmark=XXX.
Is there a way I could map that number to the name of the actual context when I set it up originally with the --selctx option in iptables? If that is not possible do you plan to include such feature in the upcoming versions of netfilter?
Apart from SMACK, I don't think the kernel has knowledge about any names of sorts, especially since SELinux labels seem to be able to be longer than 8 chars.

Quoted 6 lines

Quoted 2 lines
So if anything, it would be done so in conntrack-tools which you should be using over /proc anyway.
Is there any way I could do this with conntrack-tools? The only option I could see on conntrack (the executable) is by using a filter and specifying -c or --secmark (a number) which isn't what I am after!

Basically conntrack -L. You just need to write the patch that does the secmark->name translation. :-)

Mr Dash Four

author

2010-09-20 12:42 UTC #4 lore raw

Quoted 3 lines

Basically conntrack -L. You just need to write the patch that does the secmark->name translation. :-)

Actually, I've got a better idea!

I spend good part of the last hour looking at the source of iptables (v1.4.7 as this is what comes out of my FC13 as the 'latest' rpm) and found this little nugget:

=====<xt_SECMARK.h>=================
struct xt_secmark_target_selinux_info {
__u32 selsid;
char selctx[SECMARK_SELCTX_MAX];
};
===================================

=====<libxt_SECMARK.c>===============
static void print_secmark(const struct xt_secmark_target_info *info) {
switch (info->mode) {
case SECMARK_MODE_SEL:

       printf("selctx %s ", info->u.sel.selctx);\
       break;

default:

       xtables_error(OTHER_PROBLEM, PFX "invalid mode %hhu\n", info->mode);

}
}

static void SECMARK_print(const void *ip, const struct xt_entry_target *target,
int numeric)
{
const struct xt_secmark_target_info *info =

       (struct xt_secmark_target_info*)(target)->data;

printf("SECMARK ");
print_secmark(info);
}
===================================

The output of SECMARK_print is seen when I list the mangle table with iptables ('iptables -t mangle -L -n' for example) and there is the SELinux context in full view as I originally registered the rule match with. So, if I am to kindly ask the devs maintaining the iptables code to change the above function to include the following line:

printf("selctx %s [%u]", info->u.sel.selctx,info->u.sel.selsid);\

instead of:

printf("selctx %s ", info->u.sel.selctx);\

I would, at least, have an idea of what SELinux contexts maps to which number (I am assuming that 'selsid' is the actual number printed in the 'secmark=XXX' - I haven't gone that far in the code yet to verify this!).

Ideally, I would *love* to have a separate branch in, say '/proc/net/selctx', listing all registered contexts with iptables/netfilter together with their numbers (basically a printout of the whole xt_secmark_target_selinux_info struct as defined above).

That would not be too much to ask now, would it? :-)

Mr Dash Four

author

2010-09-20 18:15 UTC #5 lore raw

Further to my earlier post today, I can now confirm that the number shown in the secmark=XXX output IS the same as the "selctx" field in xt_SECMARK.h/libxt_SECMARK.c so it won't be that difficult to extract and incorporate the whole struct in some way suitable for visualisation (here's hoping!).

Tom Eastep

2010-09-20 21:49 UTC #6 lore raw

In reply to Mr Dash Four

Quoted 6 lines · Mr Dash Four

The output of SECMARK_print is seen when I list the mangle table with iptables ('iptables -t mangle -L -n' for example) and there is the SELinux context in full view as I originally registered the rule match with. So, if I am to kindly ask the devs maintaining the iptables code to change the above function to include the following line:

Quoted 6 lines

printf("selctx %s [%u]", info->u.sel.selctx,info->u.sel.selsid);\
instead of:
printf("selctx %s ", info->u.sel.selctx);\

That breaks iptables-save/-restore. The attached patch does not.

-Tom

Signature · 4 lines

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

libxt_SECMARK.c renamed from libxt_SECMARK.c~ +14 -2

@@ -65,7 +65,7 @@
 {
 	switch (info->mode) {
 	case SECMARK_MODE_SEL:
-		printf("selctx %s ", info->u.sel.selctx);\
+	        printf("selctx %s [%u] ", info->u.sel.selctx, info->u.sel.selsid);
 		break;
 	
 	default:

@@ -83,13 +83,25 @@
 	print_secmark(info);
 }
 
+static void save_secmark(const struct xt_secmark_target_info *info)
+{
+	switch (info->mode) {
+	case SECMARK_MODE_SEL:
+		printf("selctx %s ", info->u.sel.selctx);\
+		break;
+	
+	default:
+		xtables_error(OTHER_PROBLEM, PFX "invalid mode %hhu\n", info->mode);
+	}
+}
+
 static void SECMARK_save(const void *ip, const struct xt_entry_target *target)
 {
 	const struct xt_secmark_target_info *info =
 		(struct xt_secmark_target_info*)target->data;
 
 	printf("--");
-	print_secmark(info);
+	save_secmark(info);
 }
 
 static struct xtables_target secmark_target = {

Jan Engelhardt

2010-09-20 23:26 UTC #7 lore raw

Quoted 3 lines · Tom Eastep

Quoted 1 line
printf("selctx %s ", info->u.sel.selctx);\
That breaks iptables-save/-restore. The attached patch does not.

But still has the rogue \ at EOL.

Tom Eastep

2010-09-20 23:55 UTC #8 lore raw

Quoted 7 lines · Jan Engelhardt

Quoted 3 lines · Tom Eastep
Quoted 1 line
printf("selctx %s ", info->u.sel.selctx);\
That breaks iptables-save/-restore. The attached patch does not.
But still has the rogue \ at EOL.

Yes, I see that harmless character is in the current source and that I failed to delete it when I cloned the function.

-Tom

Signature · 4 lines

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

Mr Dash Four

author

2010-09-21 09:59 UTC #9 lore raw

In reply to Jan Engelhardt

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
printf("selctx %s ", info->u.sel.selctx);\
That breaks iptables-save/-restore. The attached patch does not.
But still has the rogue \ at EOL.

Splitting hairs!

The real question is - when would these pairs (SELinux/SELsid) be included in the new release of iptables/netfilter (as I posted before - ideally, as a separate branch in /proc/net)?

Mr Dash Four

author

2010-09-21 20:13 UTC #10 lore raw

Quoted 13 lines

Quoted 6 lines
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.

Eric Paris

2010-09-21 20:26 UTC #11 lore raw

Quoted 17 lines · Mr Dash Four

Quoted 17 lines
Quoted 6 lines
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.

Quoted 4 lines

Quoted 4 lines
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)

-Eric

Eric Paris

2010-09-21 21:00 UTC #12 lore raw

Quoted 28 lines · Eric Paris

Quoted 17 lines · Mr Dash Four
Quoted 17 lines
Quoted 6 lines
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.
Quoted 4 lines
Quoted 4 lines
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 :)

Quoted 8 lines

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

Mr Dash Four

author

2010-09-21 22:38 UTC #13 lore raw

Quoted 9 lines

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

Bravo! It even says 'unlabeled' (wrong spelling you see, though I know that is not your fault, relax - I won't blame you for that). I assume that meaningless secmark number was 0, is that correct?

Quoted 5 lines

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

My guess would be that whoever needed it would have been using the kernel functions to do anything meaningful with it, unless, of course, a simple check for does it/does it not have SELinux context defined (i.e. secmark<>0).

Jan Engelhardt

2010-09-21 22:42 UTC #14 lore raw

In reply to Eric Paris

Quoted 8 lines · Eric Paris

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

I think that rather than bloating ancient procfs files with more info, the respective userspace tool should be augmented by secmark name resolution instead. Then we would also not need change anything inside the kernel, or its interfaces to userspace.

Mr Dash Four

author

2010-09-21 22:51 UTC #15 lore raw

Quoted 8 lines

Quoted 7 lines
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

Quoted 5 lines

I think that rather than bloating ancient procfs files with more info, the respective userspace tool should be augmented by secmark name resolution instead. Then we would also not need change anything inside the kernel, or its interfaces to userspace.

The point Eric made (and is a very good one) is that this number should not be there - at all!

Who would make sense of that number?

This number is only (remotely) useful if somebody is parsing secmark=xxx for simple <>0 checks - i.e. to find out whether there is a context defined for that connection. I agree that there should be userspace function for converting sids to text, but nfs_conntrack, in my view, should contain the full context (so, in other words - we should have both).

Eric Paris

2010-09-21 23:10 UTC #16 lore raw

In reply to Jan Engelhardt

Quoted 7 lines · Jan Engelhardt

Quoted 5 lines · Eric Paris
My current patch looks like so:
cat /proc/net/nfs_conntrack

Quoted 8 lines

Quoted 3 lines
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
I think that rather than bloating ancient procfs files with more info, the respective userspace tool should be augmented by secmark name resolution instead. Then we would also not need change anything inside the kernel, or its interfaces to userspace.

It is not possible for userspace to resolve these numbers to something useful. They are dynamically generated numbers which are just kernel internal helpers. This is the only known place that the kernel shows its underpants to in public and it should be fixed. My only question is if fixing like this it is likely to break anything. Otherwise I'm going to hard code those to 0 or 1 and export the label in a new field....

-Eric

Jan Engelhardt

2010-09-21 23:35 UTC #17 lore raw

Quoted 8 lines · Eric Paris

Quoted 8 lines
Quoted 7 lines
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

Quoted 8 lines

Quoted 4 lines
I think that rather than bloating ancient procfs files with more info, the respective userspace tool should be augmented by secmark name resolution instead. Then we would also not need change anything inside the kernel, or its interfaces to userspace.
It is not possible for userspace to resolve these numbers to something useful. They are dynamically generated numbers which are just kernel internal helpers.

Ok so I had a misconception about how ls -Z worked. Guess the UID/GID stuff misled pretty hard.

Quoted 7 lines

This is the only known place that the kernel shows
its underpants to in public and it should be fixed. My only question is if fixing like this it is likely to break anything.
Otherwise I'm
going to hard code those to 0 or 1 and export the label in a new field....

The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter.

For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it.

Eric Paris

2010-09-23 18:39 UTC #18 lore raw

Quoted 30 lines · Jan Engelhardt

Quoted 8 lines · Eric Paris
Quoted 8 lines
Quoted 7 lines
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
Quoted 8 lines
Quoted 4 lines
I think that rather than bloating ancient procfs files with more info, the respective userspace tool should be augmented by secmark name resolution instead. Then we would also not need change anything inside the kernel, or its interfaces to userspace.
It is not possible for userspace to resolve these numbers to something useful. They are dynamically generated numbers which are just kernel internal helpers.
Ok so I had a misconception about how ls -Z worked. Guess the UID/GID stuff misled pretty hard.
Quoted 7 lines
This is the only known place that the kernel shows
its underpants to in public and it should be fixed. My only question is if fixing like this it is likely to break anything.
Otherwise I'm
going to hard code those to 0 or 1 and export the label in a new field....

Quoted 6 lines

The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter.
For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it.

How does one use the secmark netlink socket? How do I test my code? I'm sure this is an obvious question for most of you, but not for me :)

-Eric

Jan Engelhardt

2010-09-23 18:49 UTC #19 lore raw

Quoted 9 lines · Eric Paris

Quoted 9 lines
Quoted 4 lines
Â Otherwise I'm
going to hard code those to 0 or 1 and export the label in a new field....
The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter.

Quoted 6 lines

Quoted 2 lines
For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it.
How does one use the secmark netlink socket? How do I test my code? I'm sure this is an obvious question for most of you, but not for me :)

There exists a CTA_SECMARK in nfnetlink_conntrack.h. You leave that as-is, and add a new CTA_SECNAME. Subsequently, in nf_conntrack_netlink.c, you replace NLA_PUT_BE32(skb, CTA_SECMARK, ...) with the appropriate NLA_PUT_STRING(skb, CTA_SECNAME, ...) or whatever the nla_put routine was called. Adjust the preallocation size too:
- + nla_total_size(sizeof(u_int32_t)) /* CTA_SECMARK */
+ + nla_total_size(??) /* CTA_SECNAME */

and that should do it for the kernel side. Simiarly on the userspace side.

Eric Paris

2010-09-23 18:52 UTC #20 lore raw

Quoted 25 lines · Jan Engelhardt

Quoted 9 lines · Eric Paris
Quoted 9 lines
Quoted 4 lines
Otherwise I'm
going to hard code those to 0 or 1 and export the label in a new field....
The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter.
Quoted 6 lines
Quoted 2 lines
For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it.
How does one use the secmark netlink socket? How do I test my code? I'm sure this is an obvious question for most of you, but not for me :)
There exists a CTA_SECMARK in nfnetlink_conntrack.h. You leave that as-is, and add a new CTA_SECNAME. Subsequently, in nf_conntrack_netlink.c, you replace NLA_PUT_BE32(skb, CTA_SECMARK, ...) with the appropriate NLA_PUT_STRING(skb, CTA_SECNAME, ...) or whatever the nla_put routine was called. Adjust the preallocation size too:
- + nla_total_size(sizeof(u_int32_t)) /* CTA_SECMARK */
+ + nla_total_size(??) /* CTA_SECNAME */

Quoted 2 lines

and that should do it for the kernel side. Simiarly on the userspace side.

No, the question was more basic. What is the userspace tool?

-Eric

Jan Engelhardt

2010-09-23 18:57 UTC #21 lore raw

Quoted 26 lines · Eric Paris

Quoted 25 lines · Jan Engelhardt
Quoted 9 lines · Eric Paris
Quoted 9 lines
Quoted 4 lines
Otherwise I'm
going to hard code those to 0 or 1 and export the label in a new field....
The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter.
Quoted 6 lines
Quoted 2 lines
For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it.
How does one use the secmark netlink socket? How do I test my code? I'm sure this is an obvious question for most of you, but not for me :)
There exists a CTA_SECMARK in nfnetlink_conntrack.h. You leave that as-is, and add a new CTA_SECNAME. Subsequently, in nf_conntrack_netlink.c, you replace NLA_PUT_BE32(skb, CTA_SECMARK, ...) with the appropriate NLA_PUT_STRING(skb, CTA_SECNAME, ...) or whatever the nla_put routine was called. Adjust the preallocation size too:
- + nla_total_size(sizeof(u_int32_t)) /* CTA_SECMARK */
+ + nla_total_size(??) /* CTA_SECNAME */

Quoted 4 lines

Quoted 2 lines
and that should do it for the kernel side. Simiarly on the userspace side.
No, the question was more basic. What is the userspace tool?

git://git.netfilter.org/libnetfilter_conntrack is the library where CTA_SECMARK is parsed (when receiving from kernel) - parse.c - and built (when sending to the kernel) - build.c, and

git://git.netfilter.org/conntrack-utils makes use of that library and provides the actual conntrack(8) binary that people run.

./conntrack -L is then what you use to test the changes.

Hope that helps,
Jan

Eric Paris

2010-09-23 18:58 UTC #22 lore raw

Quoted 4 lines · Jan Engelhardt

Quoted 1 line · Eric Paris
No, the question was more basic. What is the userspace tool?

Quoted 8 lines

git://git.netfilter.org/libnetfilter_conntrack is the library where CTA_SECMARK is parsed (when receiving from kernel) - parse.c - and built (when sending to the kernel) - build.c, and
git://git.netfilter.org/conntrack-utils makes use of that library and provides the actual conntrack(8) binary that people run.
./conntrack -L is then what you use to test the changes.

That's perfect thanks!

-Eric

Mr Dash Four

author

2010-09-23 19:20 UTC #23 lore raw

In reply to Jan Engelhardt

Quoted 3 lines

./conntrack -L is then what you use to test the changes.

Have I missed something? Are you actually suggesting that in order for me to see the new secmark changes (SELinux context shown in its full text glory instead of that useless number) I have to install conntrack-utils and use conntrack (the executable)?

What happens to the new /nf(s)_conntrack and iptables -L? I assumed, as Eric suggested earlier, that would also be possible. Is that not still the case?

Jan Engelhardt

2010-09-23 19:51 UTC #24 lore raw

Quoted 9 lines · Mr Dash Four

Quoted 2 lines
./conntrack -L is then what you use to test the changes.
Have I missed something? Are you actually suggesting that in order for me to see the new secmark changes (SELinux context shown in its full text glory instead of that useless number) I have to install conntrack-utils and use conntrack (the executable)?
What happens to the new /nf(s)_conntrack

If anything, secmark=x be removed. Abusing procfs is deprecated. No userspace program depends on it.

Quoted 1 line

and iptables -L?

As was said earlier (by Eric?), the secmark/u32 value is useless and that secname (aka. selctx) should only ever be used. That is already the case with x_tables.

Mr Dash Four

author

2010-09-23 20:05 UTC #25 lore raw

Quoted 7 lines

Quoted 3 lines
What happens to the new /nf(s)_conntrack
If anything, secmark=x be removed. Abusing procfs is deprecated. No userspace program depends on it.

Sorry, but I've never suggested that useless number be kept in any shape or form anywhere (please read my posts on this very thread)!

There was a patch from Eric (I think about 2 days ago) showing secmark=<selctx> in the output of nfs_conntrack and I assumed that will be adopted. Is that no longer the case and if so why?

Quoted 8 lines

Quoted 3 lines
and iptables -L?
As was said earlier (by Eric?), the secmark/u32 value is useless and that secname (aka. selctx) should only ever be used. That is already the case with x_tables.

I've never suggested that the u32 was ever useful (it was actually you, who asked me to devise a patch translating it into the actual text when I suggested that this number is pretty useless, remember?).

Again, I assume that when I use "cat /proc/net/nf(s)_conntrack" I would be able to see the proper translation of the SELinux context for all connections and not that useless number (the whole reason for me starting this thread). I think I've made myself perfectly clear on this.

Mr Dash Four

author

2010-09-23 20:18 UTC #26 lore raw

In reply to Jan Engelhardt

Quoted 7 lines

Quoted 3 lines
What happens to the new /nf(s)_conntrack
If anything, secmark=x be removed. Abusing procfs is deprecated. No userspace program depends on it.

I've just read the above again. Are you actually suggesting that no program in userspace uses /proc/net/nf_conntrack? If so, you are mistaken my friend!

I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections.

So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

Eric Paris

2010-09-23 20:34 UTC #27 lore raw

Quoted 11 lines · Mr Dash Four

Quoted 7 lines
Quoted 3 lines
What happens to the new /nf(s)_conntrack
If anything, secmark=x be removed. Abusing procfs is deprecated. No userspace program depends on it.
I've just read the above again. Are you actually suggesting that no program in userspace uses /proc/net/nf_conntrack? If so, you are mistaken my friend!

Quoted 7 lines

I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections.
So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

I will send a patch series for which the answer is 'yes' and we shall see what everyone agrees to commit.

-Eric

Mr Dash Four

author

2010-09-23 20:38 UTC #28 lore raw

Quoted 4 lines

I will send a patch series for which the answer is 'yes' and we shall see what everyone agrees to commit.

Thank you Eric!

Seeing the SELinux context (as text!) is vital in my line of work and I don't see the need to bloat (no offence, Jan!) my distros unnecessarily with additional tools for which I have no use whatsoever!

Jan Engelhardt

2010-09-23 20:53 UTC #29 lore raw

In reply to Eric Paris

Quoted 7 lines · Eric Paris

Quoted 7 lines
I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections. So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

That's like saying we need /proc/self/df just so that we can know the fill state of disks without resorting to a userspace tool (oooh~ god forbid!).

Mr Dash Four

author

2010-09-23 20:56 UTC #30 lore raw

Quoted 9 lines

Quoted 8 lines
Quoted 8 lines
I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections. So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

Quoted 3 lines

That's like saying we need /proc/self/df just so that we can know the fill state of disks without resorting to a userspace tool (oooh~ god forbid!).

What is that suppose to mean? Are you suggesting that for the dubious privilege of seeing secmark=<selctx> - the way it should have been developed in the first place - as oppose to secmark=XXX as was the case up until now, I have to install your set of tools? I don't think so!

Jan Engelhardt

2010-09-23 21:23 UTC #31 lore raw

Quoted 9 lines · Mr Dash Four

Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections. So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

Quoted 7 lines

Quoted 2 lines
That's like saying we need /proc/self/df just so that we can know the fill state of disks without resorting to a userspace tool (oooh~ god forbid!).
What is that suppose to mean? Are you suggesting that for the dubious privilege of seeing secmark=<selctx> - the way it should have been developed in the first place - as oppose to secmark=XXX as was the case up until now, I have to install your set of tools? I don't think so!

The trend is clear. If we were procfs fanboys, we would not need sysfs. Or securityfs. Or debugfs. We'd have everything in /proc.

You can think whatever you want. It's just hypocritical wanting to add a feature to an infrastructure that practically every developer consented to not abuse further.

Mr Dash Four

author

2010-09-23 21:38 UTC #32 lore raw

Quoted 10 lines

Quoted 6 lines
What is that suppose to mean? Are you suggesting that for the dubious privilege of seeing secmark=<selctx> - the way it should have been developed in the first place - as oppose to secmark=XXX as was the case up until now, I have to install your set of tools? I don't think so!
The trend is clear. If we were procfs fanboys, we would not need sysfs. Or securityfs. Or debugfs. We'd have everything in /proc.

Please read again what I wrote above. Where did I state that I need "everything in /proc"? I am merely suggesting a fix for what should have been released in the first place by correcting the value of secmark to show the proper context instead of a number which means absolutely nothing to anyone.

Quoted 1 line

You can think whatever you want.

I find the above rather condescending - what is that supposed to mean? I think that you need a bit of help with anger management.

Quoted 4 lines

It's just hypocritical wanting to
add a feature to an infrastructure that practically every developer consented to not abuse further.

Again, read what I wrote above - I do not ask for an addition, just a simple correction of something which should have been done properly in the first place. How is that "hypocritical"?

Jan Engelhardt

2010-09-23 22:12 UTC #33 lore raw

Quoted 9 lines · Mr Dash Four

Quoted 9 lines
Quoted 8 lines
What is that suppose to mean? Are you suggesting that for the dubious privilege
of seeing secmark=<selctx> - the way it should have been developed in the first
place - as oppose to secmark=XXX as was the case up until now, I have to install your set of tools? I don't think so!

Quoted 5 lines

Quoted 2 lines
The trend is clear. If we were procfs fanboys, we would not need sysfs. Or securityfs. Or debugfs. We'd have everything in /proc.
Please read again what I wrote above. Where did I state that I need "everything in /proc"?

Nowhere! It was a reply with the linguistic element of cynism, in case that was missed, or not explicitly marked with smilies or other symbolic figured indicating such.

Quoted 4 lines

I am merely suggesting a fix for what should have been released in the first place by correcting the value of secmark to show the proper context instead of a number which means absolutely nothing to anyone.

Exactly. Since the number is useless to most people, the procfs file practically never had the feature "display useful secmark". Which means that changing it is a feature addition rather than a bugfix.

Mr Dash Four

author

2010-09-23 22:30 UTC #34 lore raw

Quoted 11 lines

Quoted 6 lines
I am merely suggesting a fix for what should have been released in the first place by correcting the value of secmark to show the proper context instead of a number which means absolutely nothing to anyone.
Exactly. Since the number is useless to most people, the procfs file practically never had the feature "display useful secmark". Which means that changing it is a feature addition rather than a bugfix.

Actually, no! The last time I checked this field was named secmark, not secnumber! By its very name, secmark should have been displaying ... well ... the secmark of that particular connection!

Whoever designed that part of the interface (it wasn't you by any chance, was it?) thought, wrongly, that secmark means 'show-me-the-internal-number-the-kernel-uses-to-identify-that-security-mark-for-that-particular-connection'! That, as already Eric pointed out, was wrong - the kernel should never show its underpants in userspace (very well-put, I have to say!). So, by all definitions - this is a bug (and not an additional feature) and it has to be corrected.

What I cannot understand is this - why are you so stuck up on this not getting corrected - are you afraid that if the secmark field bug is fixed your precious conntrack-utils won't have as much appeal?

Eric Paris

2010-09-23 22:42 UTC #35 lore raw

Quoted 3 lines · Mr Dash Four

Whoever designed that part of the interface (it wasn't you by any chance,
was it?) thought, wrongly, that secmark means 'show-me-the-internal-number-the-kernel-uses-to-identify-that-security-mark-for-that-particular-connection'!

It was written when secmark was implemented by an SELinux hacker (and an ex-netfilter hacker) named James Morris who should have known better.

James, I just cc'd you on this thread. Basically the conntrack code exported the selinux sid instead of the context to userspace via both procfs and its netlink interface. Mr Dash Four would like to show the context in both places (I'm going to stop showing the sid everywhere no matter what). Jan would like the netlink interface to show the context and the procfs interface to show nothing (since procfs is deprecated and what we have been showing has obviously gone unused)

I'll throw in my 2 cents. I would like to see the proc interface 'fixed' or 'enhanced', I don't care what it is called, to show the name. However my patch series (now 6 patches long) splits the netlink and the procfs changes into separate pieces which can be selectively applied.

If we can come to a consensus on the question of 'should we show nothing at all or the context in the procfs interface' then we can start the question of who wants to carry my series (since it straddles the security and the netfilter code)

-Eric

p.s. I'll send the series once I get the conntrack userspace code to understand my changes to make sure I didn't screw anything up.

Jan Engelhardt

2010-09-23 23:59 UTC #36 lore raw

In reply to Mr Dash Four

Quoted 6 lines · Mr Dash Four

Quoted 6 lines
Quoted 5 lines
I am merely suggesting a fix for what should have been released in the first place by correcting the value of secmark to show the proper context instead of a number which means absolutely nothing to anyone.

Quoted 7 lines

Quoted 4 lines
Exactly. Since the number is useless to most people, the procfs file practically never had the feature "display useful secmark". Which means that changing it is a feature addition rather than a bugfix.
Actually, no! The last time I checked this field was named secmark, not secnumber! By its very name, secmark should have been displaying ... well ... the secmark of that particular connection!

In a way, it did display the secmark. :-) Just like ipt_LOG prints nfmark or IP addresses. The values may not mean much to the outside world, but that's what we have DNS and selctx (James's original naming) for.

Quoted 3 lines

What I cannot understand is this - why are you so stuck up on this not getting corrected - are you afraid that if the secmark field bug is fixed your precious conntrack-utils won't have as much appeal?

It is not "my" conntrack-utils by any means. If users would not constantly insist on using outdated interfaces (and I _do_ grant things their transition time), and if maintainers would not always give in to these users, we would have less code to worry about, or even have these discussions.

Tom Eastep

2010-09-24 00:24 UTC #37 lore raw

Quoted 6 lines · Jan Engelhardt

It is not "my" conntrack-utils by any means. If users would not constantly insist on using outdated interfaces (and I _do_ grant things their transition time), and if maintainers would not always give in to these users, we would have less code to worry about, or even have these discussions.

So if the 'conntrack' utility invokes the sid->secctx translation in formatting it's -L output then everyone should be happy. Non-programmers get the text output that they want and there is no need to extend the deprecated /proc interface.

-Tom

Signature · 4 lines

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

Mr Dash Four

author

2010-09-24 00:32 UTC #38 lore raw

Quoted 6 lines

So if the 'conntrack' utility invokes the sid->secctx translation in formatting it's -L output then everyone should be happy. Non-programmers get the text output that they want and there is no need to extend the deprecated /proc interface.

The point I am making (well, actually, two points) is this:

1) The existing /proc interface has secmark, albeit showing the wrong output/field, whatever you want to call it and, for me, that isn't right and needs to be fixed; and

2) Why should I have bloat my system any further and install yet another set of tools (which will have no further use apart from 'conntrack -L') when I can get exactly the same functionality via the OS without further hassle of having to maintain the said set of tools?

Jan Engelhardt

2010-09-24 01:18 UTC #39 lore raw

In reply to Tom Eastep

Quoted 10 lines · Tom Eastep

Quoted 6 lines · Jan Engelhardt
It is not "my" conntrack-utils by any means. If users would not constantly insist on using outdated interfaces (and I _do_ grant things their transition time), and if maintainers would not always give in to these users, we would have less code to worry about, or even have these discussions.
So if the 'conntrack' utility invokes the sid->secctx translation in

As Eric mentioned, sid->secctx translation should already be done in the kernel since sid are not meant to be seen/used on the outside, and I agree to that if that is how selinux works. (And thus the discussion is mostly about whether the secctx is to be reported in procfs, or via netlink.)

Quoted 3 lines

formatting it's -L output then everyone should be happy. Non-programmers get the text output that they want and there is no need to extend the deprecated /proc interface.

Mr Dash Four

author

2010-09-24 00:27 UTC #40 lore raw

In reply to Jan Engelhardt

Quoted 2 lines

In a way, it did display the secmark. :-)

Of course it doesn't. This is a number generated internally by the sel engine (it is called sid). End users were never meant to see this number - at all. selctx is the field which is designed for user space and for 'general' consumption.

Quoted 5 lines

Just like ipt_LOG prints
nfmark or IP addresses. The values may not mean much to the outside world, but that's what we have DNS and selctx (James's original naming) for.

Again, all of the above is meant to be in userspace, sid isn't.

Quoted 3 lines

If users would not
constantly insist on using outdated interfaces (and I _do_ grant things their transition time),

Who are you to judge what consumers - both users and developers alike - should or shouldn't use?

Quoted 4 lines

and if maintainers would not always
give in to these users, we would have less code to worry about, or even have these discussions.

Yeah right, so if I need to see a secmark on a particular connection instead of typing a simple 'cat /proc/net/nf_conntrack', or, as is in my case use an existing tool (Shorewall) to check for such contexts, lets just bloat my system with yet another set of useless tools, install conntrack-utils and execute 'conntrack -L' for that privilege instead?! You should be working for Microsoft!

I am not, for a moment, suggesting that netfilter tools should not be able to map and get the context - what I am saying is that consumers (both users and developers) should be given a choice to use both methods - either via /proc (as is the case right now) as well as by other 3rd party userspace tools - the choice is theirs to make.

Jan Engelhardt

2010-09-23 20:42 UTC #41 lore raw

In reply to Mr Dash Four

Quoted 8 lines · Mr Dash Four

Quoted 4 lines
Quoted 1 line
What happens to the new /nf(s)_conntrack
If anything, secmark=x be removed. Abusing procfs is deprecated. No userspace program depends on it.
I've just read the above again. Are you actually suggesting that no program in userspace uses /proc/net/nf_conntrack? If so, you are mistaken my friend!

No program hard-depends on "secmark=" (not: no program depends on procfs/nfct). That field does not show up if you have SECMARK disabled - it is guarded by #ifdef - so any parsers out there have to cater for its absence. In other words, it is safe to remove the field from the output.

Quoted 6 lines

I use it a lot via 'cat' and Shorewall (via 'shorewall show connections'). I use it for one particular reason - to track SELinux contexts (text, NOT numbers!) on active connections.
So, am I going to see the SELinux context for each connection in text without the need to use conntrack-utils or not (simple 'yes' or 'no' answer will do)?

I would prefer for the procfs interface to cease existing. At the very least to be not added to any more, per consensus
http://markmail.org/message/h7qeomrtjjjtptio

Mr Dash Four

author

2010-09-23 20:53 UTC #42 lore raw

Quoted 7 lines

No program hard-depends on "secmark=" (not: no program depends on procfs/nfct). That field does not show up if you have SECMARK disabled - it is guarded by #ifdef - so any parsers out there have to cater for its absence. In other words, it is safe to remove the field from the output.

Why should that field be removed though - please give me a valid reason? The earlier suggestion, by Eric, was to replace the value of it with its proper text - this is how it should have been done in the first place!

Quoted 4 lines

I would prefer for the procfs interface to cease existing. At the very least to be not added to any more, per consensus
http://markmail.org/message/h7qeomrtjjjtptio

See my earlier reply - I do not see the need to bloat my images and add yet another set of tools for which I have no use whatsoever!

For what? For the dubious privilege to be able to see SELinux contexts in text when I could continue to use secmark in the form in which it should have been designed/developed in the first place - with its proper SELinux context showing instead of that useless number?

Mr Dash Four

author

2010-09-21 22:29 UTC #43 lore raw

In reply to Eric Paris

Quoted 5 lines

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 :)

No argument there!

Quoted 9 lines

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)

Again, we are in agreement - 100%

What baffles me really is how has this survived for so long?

The secmark field number has been there, I assume, for ages and yet nobody could make sense of that number let alone, as you rightly pointed out, raise the issue that this number should not be there in the first place!

Tom Eastep

2010-09-22 02:25 UTC #44 lore raw

In reply to Eric Paris

Quoted 19 lines · Eric Paris

Quoted 17 lines · Mr Dash Four
Quoted 17 lines
Quoted 6 lines
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.

Quoted 8 lines

Quoted 4 lines
Quoted 4 lines
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 :)

My patch took two minutes to concoct and I make no claim of excellence :)

-Tom

Signature · 4 lines

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________