Re: SECMARK support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 18, 2018 at 02:56:02AM +0200, Florian Westphal wrote:
> Christian Göttsche <cgzones@xxxxxxxxxxxxxx> wrote:
> > Hi,
> > after I found a nice tutorial [1], I started to hack some code [2].
> > Is it the correct approach to introduce a new kernel module and a new
> > nftables statement?
> 
> Yes and no :-)
> 
> The problem is that current nft_meta.c uses the 32bit secmark id,
> which, as far as i know is not useable from userspace.

Yes, we have to deprecate this / should not be used.

> This will need something similar to what you propose, i.e.
> text-string sent to kernel for conversion purpose.
> 
> > Is there an easy way to attach the secmark to the parent connection,
> > so that all packets of the same connection inherit it?
> 
> Yes, thats what xt_CONNSECMARK.c does -- copies skb->secmark to the
> secmark stored in nf_conn->secmark.
> 
> Back to the topic at hand.
> I think SECMARK equivalent should live in nft_meta.c.
> 
> As it looks like we can't discover correct secid (32bit value)
> from userspace we will need to pass the full string, as you did.

Right. Last time we talked to SELinux/Security people they told us
even if there would be a way to lookup for the ID, it won't be stable
across policy reload.

> Simplest version is to merge your patch into nft_meta.c, in the
> "set" part, and make the init() function translate it to the 32bit
> immedidate, this would pretty much look like your patch.
> 
> The disadvantage of passing it as string is that we can't use
> maps and the like for setting the value, e.g.
> 
> meta secmark set tcp dport map { 22 : system_u:object_r:x_ssh_packet:s0,
>                                { 80 : system_u:object_r:x_http_packet:s0, }

The approach that Florian describes is the way to go IMO too.

> would not work as we can't pass n strings to the kernel, we'd need one
> rule for each label.
> 
> I think the best solution would be to add objref support for the
> selctx names.
>
> We'd need a new NFT_OBJECT_SELCTX in kernel, that gets the security
> label and can do the conversion to the 32bit id.
> 
> This would live in nft_meta.c, similar to nft_ct_helper_obj_type living
> in nft_ct.c .
> 
> static struct nft_object_ops nft_selctx_obj_type;
> 
> 1. policy that gets the NLA_STRING
> 2. init() function that convers string -> id
> 3. dump() function that dumps string back to userspace
> 4. eval() function that sets skb->secmark = priv->id;
> 
> On frontend side users would do:
> 
> nft add secctx filter test-ssh { selctx "system_u:object_r:x_ssh_packet:s0"; }
> nft add rule filter input tcp dport 22 meta secmark set "test-ssh"
> 
> This looks more cumbersome but it would allow use of "map" syntax as
> outlined above since this gives nft machinery the needed info to know that
> "test-ssh" is a security context and it would invoke the appropriate objref
> function to internally convert the name -> id.
>
> If you'd like to work on this (its not easy) I'd be happy to provide
> help/guidance to get this merged into the kernel/nftables.
> 
> [ NB: I suck with nft grammar, perhaps this should be a more simple
> 
> nft add secctx filter test-ssh "system..." without any extra {},
> but thats a minor point. ]

No worries, this is very much the last thing, so we can revisit this.



[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux