Christian Göttsche <cgzo...@googlemail.com> wrote:
> I stuck a bit with the nft cli coding.
>
> By now the following works:
>
> $ nft add map inet filter secmapping { type inet_service : secmark \; }
> $ nft add rule inet filter input tcp dport 21 secmark
> \"system_u:object_r:ftp_server_packet_t:s0\"
> $ nft add rule inet filter input secmark name tcp dport map @secmapping
nft needs to support something like this:
nft add secmark inet filter sshtag "system_u:object_r:ssh_server_packet_t:s0"
nft list secmarks
which creates a new secmark object named 'sshtag' with a value of "system_u ..."
so users can then use that object:
nft add rule inet filter input meta secmark set sshtag
or
nft add map inet filter secmapping { type inet_service : secmark \; }
nft add element inet filter secmapping { 22 : sshtag }
nft add rule inet filter input meta secmark set tcp dport map @secmapping
(sshtag is arbitrary identifier, could also be 'foo').
> $ nft list map inet filter secmapping
> Error: Could not process rule: No such file or directory
> list map inet filter secmapping
This should always work as the map exists.
It works fine for me with vanilla nft, substituting
'ifname' for 'secmark'. Does it work for you if you use vanilla
nft to create/list a map?
> Is this syntax however sane?
Looks ok, but i'd prefer to reuse 'meta set' to assign the
secmark object to a packet, secmark is to me just another packet
meta property, so i would reuse it.
For nftables.git patch, this means you'd have to remove secmark_stmt
and extend meta_stmt to handle 'meta set secmark' instead.
> kernel patch (against 4.18):
> https://github.com/cgzones/secmark/blob/master/kernel.patch
you can merge this with nft_meta.c, no need for a new expression
type.
> libnftnl patch (against 1.1.1):
> https://github.com/cgzones/secmark/blob/master/libnftnl.patch
I don't think expr/secmark.c is needed at all, obj/secmark.c should
be enough.
For example, 'ct helper' (which also uses object infrastructure):
nft --debug=netlink add rule inet filter c ct helper set cthelp
inet filter c
[ objref type 3 name cthelp ]
... so this passes the (user-defined) object name 'cthelp'
to the objref infrastructure, which will then call the ct helper object.
So this doesn't involve the ct expression.
Your kernel patch only needs to add the secmark object and its
functions to nft_meta.c, new expression code should not be needed.
When the map syntax is used, nft will just pass a register:
nft --debug=netlink add rule inet filter c ct helper set tcp dport map { 22 :
"cthelp" }
inet filter c
[ meta load l4proto => reg 1 ]
[ cmp eq reg 1 0x00000006 ]
[ payload load 2b @ transport header + 2 => reg 1 ]
[ objref sreg 1 set __objmap%d ] ; this fetches the object to use
All in all, this looks like its on track, let me know if you need more
help.
