Userspace bits were added already as part of package rebase, hence marking this one TestOnly. Kernel bits are not there yet, though.

Removing TestOnly keyword again: Syntax in output is not understood by nft anymore, so using secmark support creates rulesets which may not be fed back into nft anymore. Sadly this is consistent with upstream.

Hi. What is the status of secmark support? It appears from testing that the iptables wrapper will create secmark rules that work, though nft won't show (or create) them, and the wrapper lists them as commented out.

(In reply to Phil Sutter from comment #3)
> Removing TestOnly keyword again: Syntax in output is not understood by nft
> anymore, so using secmark support creates rulesets which may not be fed back
> into nft anymore. Sadly this is consistent with upstream.

Should be fixed upstream:

commit 3a7bdd02207f7ae6cd74af8c313d6d0f8f66f4be
Author: Christian Göttsche <cgzones>
Date:   Wed Nov 20 18:43:54 2019 +0100

    statement: make secmark statements idempotent
    
    Currently lines like
    
        ct state new meta secmark set tcp dport map @secmapping_in
    
    becomes
    
        ct state new secmark name tcp dport map @secmapping_in
    
    which is not correct.
    
    Fixes: 3bc84e5c1fdd ("src: add support for setting secmark")
    Signed-off-by: Christian Göttsche <cgzones>
    Signed-off-by: Pablo Neira Ayuso <pablo>

Hi,

(In reply to mhickman from comment #4)
> Hi. What is the status of secmark support? It appears from testing that the
> iptables wrapper will create secmark rules that work, though nft won't show
> (or create) them, and the wrapper lists them as commented out.

Yes, it is supported in iptables-nft (which uses xt_secmark module) but not in
nftables yet. The latter requires a kernel change and fresh nftables tool, both
will be available in RHEL8.2.

Cheers, Phil

To support ct secmark setting, another follow-up is required:

commit 2250296370752e516dc367f1239753b15efbea94
Author: Christian Göttsche <cgzones>
Date:   Sat Nov 23 17:22:39 2019 +0100

    src: add ability to set/get secmarks to/from connection
    
    Labeling established and related packets requires the secmark to be stored in the connection.
    Add the ability to store and retrieve secmarks like:
    
        ...
        chain input {
            ...
    
            # label new incoming packets
            ct state new meta secmark set tcp dport map @secmapping_in
    
            # add label to connection
            ct state new ct secmark set meta secmark
    
            # set label for est/rel packets from connection
            ct state established,related meta secmark set ct secmark
    
            ...
        }
        ...
        chain output {
            ...
    
            # label new outgoing packets
            ct state new meta secmark set tcp dport map @secmapping_out
    
            # add label to connection
            ct state new ct secmark set meta secmark
    
            # set label for est/rel packets from connection
            ct state established,related meta secmark set ct secmark
    
            ...
            }
        ...
    
    This patch also disallow constant value on the right hand side.
    
        # nft add rule x y meta secmark 12
        Error: Cannot be used with right hand side constant value
        add rule x y meta secmark 12
                     ~~~~~~~~~~~~ ^^
        # nft add rule x y ct secmark 12
        Error: Cannot be used with right hand side constant value
        add rule x y ct secmark 12
                     ~~~~~~~~~~ ^^
        # nft add rule x y ct secmark set 12
        Error: ct secmark must not be set to constant value
        add rule x y ct secmark set 12
                     ^^^^^^^^^^^^^^^^^
    
    This patch improves 3bc84e5c1fdd ("src: add support for setting secmark").
    
    Signed-off-by: Christian Göttsche <cgzones>
    Signed-off-by: Pablo Neira Ayuso <pablo>

Yiche, you're assigned to the kernel counterpart (bug 1715851), are you willing to test userspace bits covered by this ticket along the way?

Ok, I will also cover this ticket. Setting meta secmark/ct secmark in input/output chain.

Mark the discussion as reference: https://www.spinics.net/lists/netfilter-devel/msg56112.html

Mentioned upstream commits implicitly backported by rebase to 0.9.3.

Add SETS which type secmark failed:
# nft add table ip filter
# nft add map ip filter secmapping { type inet_service : secmark \; }
Error: Could not process rule: Invalid argument
add map ip filter secmapping { type inet_service : secmark ; }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

# uname -r
4.18.0-157.el8.x86_64

# rpm -q nftables
nftables-0.9.3-3.el8.x86_64

# rpm -q libnftnl
libnftnl-1.1.5-1.el8.x86_64

Hi Yiche,

(In reply to yiche from comment #12)
> Add SETS which type secmark failed:
> # nft add table ip filter
> # nft add map ip filter secmapping { type inet_service : secmark \; }
> Error: Could not process rule: Invalid argument
> add map ip filter secmapping { type inet_service : secmark ; }
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> # uname -r
> 4.18.0-157.el8.x86_64
> 
> # rpm -q nftables
> nftables-0.9.3-3.el8.x86_64
> 
> # rpm -q libnftnl
> libnftnl-1.1.5-1.el8.x86_64

Please note that Bug 1715851 which this ticket depends on is still in POST state - due to recent feature freeze it had to wait for exception+. So in order to test the tickets, you'll have to wait for a newer kernel.

OTOH, I'm not sure if the syntax used above will be allowed. Please also refer to testing instructions given in Bug 1715851, secmark is treated as a special object not just a set/map datatype. (Don't ask me why it is so complicated. ;)

Cheers, Phil

Thank Phil point out dependency.
Accroding to https://www.spinics.net/lists/netfilter-devel/msg64148.html. 
A map like:
map secmapping_in {
	type inet_service : secmark
	elements = { 22 : "ssh_server" }
}
should be allowed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1774