secmarks — Shorewall file





Unlike rules in the shorewall-rules(5) file, evaluation of rules in this file will continue after a match. So the final secmark for each packet will be the one assigned by the LAST rule that matches.

The secmarks file is used to associate an SELinux context with packets. It was added in Shorewall version 4.4.13.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).


If an SELinux context is associated with the packet, the context is saved in the connection. Normally, the remaining columns should be left blank.


If an SELinux context is not currently associated with the packet, then the saved context (if any) is associated with the packet. Normally, the remaining columns should be left blank.


An SELinux context.


The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT.


Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred.


This column determines the CHAIN where the SELinux context is to be applied:


It may be optionally followed by a colon and an indication of the Netfilter connection state(s) at which the context is to be applied:

:N - NEW connection
:I - INVALID connection
:NI - NEW or INVALID connection
:E - ESTABLISHED connection

Beginning with Shorewall 4.5.10, the following additional options are available

:U - UNTRACKED connection
:IU - INVALID or UNTRACKED connection
:NU - NEW or UNTRACKED connection
:NIU - NEW, INVALID or UNTRACKED connection.
SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion]

May be:

  1. An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the T in the CHAIN column.

  2. A comma-separated list of host or network IP addresses or MAC addresses.

  3. An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses.

MAC addresses must be prefixed with "~" and use "-" as a separator.

Example: ~00-A0-C9-15-39-78

You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)).

Addresses may be specified using an ipset name preceded by '+'.

DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion]

May be:

  1. An interface name. May not be used in the PREROUTING or INPUT chains. The interface name may be optionally followed by a colon (":") and an IP address list.

  2. A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support.

You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)).

Addresses may be specified using an ipset name preceded by '+'.

PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]

Protocol - ipp2p requires ipp2p match support in your kernel and iptables.

Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...]

Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See

If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed.

This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-"

SOURCE PORT(S) (sport) - [-|port-name-number-or-range[,port-name-number-or-range]...]

Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges.

USER - [!][user-name-or-number][:group-name-or-number]

This optional column may only be non-empty if the SOURCE is the firewall itself.

When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given).



program must be run by joe


program must be run by a member of the 'kids' group


program must not be run by a member of the 'kids' group

MARK - [!]value[/mask][:C]

Defines a test on the existing packet or connection mark. The rule will match only if the test returns true.

If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field.


Inverts the test (not equal)


Value of the packet or connection mark.


A mask to be applied to the mark before testing.


Designates a connection mark. If omitted, the packet mark's value is tested.


Mark the first incoming packet of a connection on the loopback interface and destined for address and tcp port 3306 with context system_u:object_r:mysqld_t:s0 and save that context in the conntrack table. On subsequent input packets in the connection, set the context from the conntrack table.


-          lo             -               ignore


#SECMARK                              CHAIN:     SOURCE  DEST       PROTO   DEST       SOURCE      USER/     MARK
#                                     STATE                                 PORT(S)    PORT(S)     GROUP
system_u:object_r:mysqld_packet_t:s0  I:N        lo  tcp     3306
SAVE                                  I:N        lo  tcp     3306
RESTORE                               I:ER




shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-mangle(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)


Frequently Used Articles

- FAQs - IPv4 Manpages - IPv6 Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.0/4.2 Documentation

Current HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages (IPv4) (IPv6) - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page