netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Alvaro Neira Ayuso <alvaroneay@gmail.com>
Cc: netfilter-devel@vger.kernel.org, kaber@trash.net
Subject: Re: [nft PATCH 4/4 v5] nft: complete reject support
Date: Thu, 9 Oct 2014 14:01:44 +0200	[thread overview]
Message-ID: <20141009120144.GA16528@salvia> (raw)
In-Reply-To: <1412090500-4564-4-git-send-email-alvaroneay@gmail.com>

On Tue, Sep 30, 2014 at 05:21:40PM +0200, Alvaro Neira Ayuso wrote:
> This patch allows to use the reject action in rules. For example:
> 
>   nft add rule filter input udp dport 22 reject

Series applies with some minor glitches, Thanks Alvaro.

See comments below.

> diff --git a/include/proto.h b/include/proto.h
> index cc1f51f..0e531b2 100644
> --- a/include/proto.h
> +++ b/include/proto.h
> @@ -252,6 +252,7 @@ enum udp_hdr_fields {
>  
>  enum tcp_hdr_fields {
>  	TCPHDR_INVALID,
> +	TCPHDR_UNSPEC = TCPHDR_INVALID,

I think we can rename all _INVALID to _UNSPEC in a follow up patch,
given that we use this to generate the dependencies.

> +static const struct symbol_table icmp_code_tbl = {
> +	.symbols	= {
> +		SYMBOL("port-unreach",		ICMP_PORT_UNREACH),

This one is shortened.

> +		SYMBOL("net-prohibited",	ICMP_NET_ANO),

This one is full long name.

I have mangled the patch to use long names all the time for
consistency. Once we get autocompletion I guess this shouldn't be a
problem.

> +static int stmt_reject_gen_dependency(struct eval_ctx *ctx, struct stmt *stmt,
> +				      struct expr *expr)
> +{
> +	struct expr *payload = NULL;
> +	struct stmt *nstmt;
> +
> +	switch (stmt->reject.type) {
> +	case NFT_REJECT_TCP_RST:
> +		if (reject_payload_gen_dependency_tcp(ctx, stmt, &payload) < 0)
> +			return -1;
> +		break;
> +	default:
> +		if (reject_payload_gen_dependency_family(ctx, stmt,
> +							 &payload) < 0)
> +			return -1;
> +		break;
> +	}

Beware with using 'default' in switch().

This is actually catching the NFT_REJECT_ICMP_UNREACH. And
NFT_REJECT_ICMPX_UNREACH seems not possible.

I mangled this to catch NFT_REJECT_ICMP_UNREACH and the default case
(which should not happen displays a bug).

> @@ -899,6 +909,59 @@ static void expr_postprocess(struct rule_pp_ctx *ctx,
>  	}
>  }
>  
> +static void stmt_reject_postprocess(struct rule_pp_ctx rctx, struct stmt *stmt)
> +{
> +	const struct proto_desc *desc, *base;
> +	int protocol;
> +
> +	switch (rctx.pctx.family) {
> +	case NFPROTO_IPV4:
> +		stmt->reject.family = rctx.pctx.family;
> +		stmt->reject.expr->dtype = &icmp_code_type;
> +		break;
> +	case NFPROTO_IPV6:
> +		stmt->reject.family = rctx.pctx.family;
> +		stmt->reject.expr->dtype = &icmpv6_code_type;
> +		break;
> +	case NFPROTO_INET:
> +		if (stmt->reject.type == NFT_REJECT_ICMPX_UNREACH)
> +			break;
> +		base = rctx.pctx.protocol[PROTO_BASE_LL_HDR].desc;
> +		desc = rctx.pctx.protocol[PROTO_BASE_NETWORK_HDR].desc;
> +		protocol = proto_find_num(base, desc);
> +		switch (protocol) {
> +		case NFPROTO_IPV4:
> +			stmt->reject.expr->dtype = &icmp_code_type;
> +			break;
> +		case NFPROTO_IPV6:
> +			stmt->reject.expr->dtype = &icmpv6_code_type;
> +			break;
> +		}
> +		stmt->reject.family = protocol;
> +		break;
> +	case NFPROTO_BRIDGE:
> +		if (stmt->reject.type == NFT_REJECT_ICMPX_UNREACH)
> +			break;
> +		base = rctx.pctx.protocol[PROTO_BASE_LL_HDR].desc;
> +		desc = rctx.pctx.protocol[PROTO_BASE_NETWORK_HDR].desc;
> +		protocol = proto_find_num(base, desc);
> +		switch (protocol) {
> +		case __constant_htons(ETH_P_IP):
> +			stmt->reject.family = NFPROTO_IPV4;
> +			stmt->reject.expr->dtype = &icmp_code_type;
> +			break;
> +		case __constant_htons(ETH_P_IPV6):
> +			stmt->reject.family = NFPROTO_IPV6;
> +			stmt->reject.expr->dtype = &icmpv6_code_type;
> +			break;
> +		default:
> +			break;

Please, have a closer look to this 'default' case. We may have
different ethertype in bridge (not just ipv4 and ipv6). Check if this
works fine in that case.

      reply	other threads:[~2014-10-09 12:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 15:21 [nft PATCH 1/4 v3] payload: generate dependency in the appropriate byteorder Alvaro Neira Ayuso
2014-09-30 15:21 ` [nft PATCH 2/4 v3] src: Enhance payload_gen_dependency() Alvaro Neira Ayuso
2014-09-30 15:21 ` [nft PATCH 3/4 v3] datatype: Enhance symbolic_constant_parse() Alvaro Neira Ayuso
2014-09-30 15:21 ` [nft PATCH 4/4 v5] nft: complete reject support Alvaro Neira Ayuso
2014-10-09 12:01   ` Pablo Neira Ayuso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141009120144.GA16528@salvia \
    --to=pablo@netfilter.org \
    --cc=alvaroneay@gmail.com \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).