decipher the secmark number from nf_conntrack/ip_conntrack

decipher the secmark number from nf_conntrack/ip_conntrack

[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?

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Monday 2010-09-20 01:04, Mr Dash Four wrote:

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Monday 2010-09-20 12:41, Mr Dash Four wrote:
>
>>>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.
>
>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. :-)

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Tom Eastep]

[-- Attachment #1.1: Type: text/plain, Size: 893 bytes --]

On 9/20/10 5:42 AM, Mr Dash Four wrote:

> 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);\
> 

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

-Tom
-- 
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 \________________________________________________

[-- Attachment #1.2: SECMARK.diff --]
[-- Type: text/plain, Size: 983 bytes --]

--- libxt_SECMARK.c~	2009-06-16 07:37:44.000000000 -0700
+++ libxt_SECMARK.c	2010-09-20 11:57:58.000000000 -0700
@@ -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 = {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Monday 2010-09-20 23:49, Tom Eastep wrote:
>> printf("selctx %s ", info->u.sel.selctx);\
>
>That breaks iptables-save/-restore. The attached patch does not.

But still has the rogue \ at EOL.

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On 9/20/10 4:26 PM, Jan Engelhardt wrote:
> 
> On Monday 2010-09-20 23:49, Tom Eastep wrote:
>>> 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
-- 
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 \________________________________________________


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Tue, Sep 21, 2010 at 4:13 PM, Mr Dash Four
<mr.dash.four@googlemail.com> 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)

-Eric

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Tue, Sep 21, 2010 at 4:26 PM, Eric Paris <eparis@parisplace.org> wrote:
> On Tue, Sep 21, 2010 at 4:13 PM, Mr Dash Four
> <mr.dash.four@googlemail.com> 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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Tuesday 2010-09-21 23:00, Eric Paris wrote:
>
>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.

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Tue, Sep 21, 2010 at 6:42 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Tuesday 2010-09-21 23:00, Eric Paris wrote:
>>
>>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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Wednesday 2010-09-22 01:10, Eric Paris wrote:
>>>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.
>
>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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Tue, Sep 21, 2010 at 7:35 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2010-09-22 01:10, Eric Paris wrote:
>>>>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.
>>
>>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.
>
>> 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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 20:39, Eric Paris wrote:
>>>
>>>  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.
>
>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.

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Thu, Sep 23, 2010 at 2:49 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Thursday 2010-09-23 20:39, Eric Paris wrote:
>>>>
>>>>  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.
>>
>>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.

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

-Eric

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 20:52, Eric Paris wrote:

>On Thu, Sep 23, 2010 at 2:49 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Thursday 2010-09-23 20:39, Eric Paris wrote:
>>>>>
>>>>>  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.
>>>
>>>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.
>
>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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Thu, Sep 23, 2010 at 2:57 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Thursday 2010-09-23 20:52, Eric Paris wrote:

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

That's perfect thanks!

-Eric

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

> `./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?

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 21:20, Mr Dash Four wrote:
>
>> `./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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Thu, Sep 23, 2010 at 4:18 PM, Mr Dash Four
<mr.dash.four@googlemail.com> wrote:
>
>>> 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)?

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

-Eric

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 22:34, Eric Paris wrote:
>>
>>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!).

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 22:56, Mr Dash Four wrote:
>
>>>> 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!).
> 
> 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.

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

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


>  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"?

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 23:38, Mr Dash Four wrote:
>
>>> 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"?

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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Eric Paris]

On Thu, Sep 23, 2010 at 6:30 PM, Mr Dash Four
<mr.dash.four@googlemail.com> wrote:

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Friday 2010-09-24 00:30, Mr Dash Four wrote:
>>> 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!

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.

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On 9/23/10 4:59 PM, Jan Engelhardt wrote:

> 
> 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
-- 
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 \________________________________________________


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Friday 2010-09-24 02:24, Tom Eastep wrote:

>On 9/23/10 4:59 PM, Jan Engelhardt wrote:
>
>> 
>> 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.)

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

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


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

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Jan Engelhardt]

On Thursday 2010-09-23 22:18, Mr Dash Four wrote:
>>> 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.

>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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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


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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Mr Dash Four]

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

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

Re: decipher the secmark number from nf_conntrack/ip_conntrack

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On 9/21/10 1:26 PM, Eric Paris wrote:
> On Tue, Sep 21, 2010 at 4:13 PM, Mr Dash Four
> <mr.dash.four@googlemail.com> 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   :)

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

-Tom
-- 
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 \________________________________________________


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]