[Buildroot] [PATCH 1/1] package/nginx: Add naxsi module option.

[Buildroot] [PATCH 1/1] package/nginx: Add naxsi module option.

[Adam Duskett]

Naxsi is a third party nginx module reads a small subset of simple rules
containing a list of known patterns involved in website vulnerabilities.
This module behaves like a DROP-by-default firewall for nginx.

The reason for the changes to the make file was because naxsi is listed
on github, and even though there is a option to specify a url for a 3rd party
module, this option only seems to work for a local file url.  As such
a EXTRA_DOWNLOADS and POST_EXTRACT_HOOKS was added to the makefile
so that the module is first downloaded and then extracted into the
nginx source directory, and then the module source is added to the
config options.  This was the cleanest solution I could find, if anybody
thinks of a cleaner solution please let me know.

The hash for the module was also added to nginx.hash.

Signed-off-by: Adam Duskett <aduskett@codeblue.com>
---
 package/nginx/Config.in  |  5 +++++
 package/nginx/nginx.hash |  1 +
 package/nginx/nginx.mk   | 14 ++++++++++++++
 3 files changed, 20 insertions(+)

diff --git a/package/nginx/Config.in b/package/nginx/Config.in
index e6f2d96..17c6c79 100644
--- a/package/nginx/Config.in
+++ b/package/nginx/Config.in
@@ -188,6 +188,11 @@ config BR2_PACKAGE_NGINX_HTTP_MAP_MODULE
 	help
 	  Enable ngx_http_map_module
 
+config BR2_PACKAGE_NGINX_HTTP_NAXSI_MODULE
+	bool "ngx_http_naxsi_module"
+	help
+	  Enable ngx_http_naxsi_module
+
 config BR2_PACKAGE_NGINX_HTTP_SPLIT_CLIENTS_MODULE
 	bool "ngx_http_split_clients_module"
 	default y
diff --git a/package/nginx/nginx.hash b/package/nginx/nginx.hash
index c4b0f89..922f16c 100644
--- a/package/nginx/nginx.hash
+++ b/package/nginx/nginx.hash
@@ -1,2 +1,3 @@
 # Locally calculated after checking pgp signature
 sha256	1fd35846566485e03c0e318989561c135c598323ff349c503a6c14826487a801	nginx-1.10.1.tar.gz
+sha256	9cc2c09405bc71f78ef26a8b6d70afcea3fccbe8125df70cb0cfc480133daba5	0.54.tar.gz
diff --git a/package/nginx/nginx.mk b/package/nginx/nginx.mk
index 5eb5488..a593c54 100644
--- a/package/nginx/nginx.mk
+++ b/package/nginx/nginx.mk
@@ -156,6 +156,14 @@ else
 NGINX_CONF_OPTS += --without-http_gzip_module
 endif
 
+ifeq ($(BR2_PACKAGE_NGINX_HTTP_NAXSI_MODULE),y)
+NGINX_HTTP_NAXSI_MODULE_VERSION = 0.54
+NGINX_HTTP_NAXSI_MODULE_SOURCE = $(NGINX_HTTP_NAXSI_MODULE_VERSION).tar.gz
+NGINX_EXTRA_DOWNLOADS = $(call github,nbs-system,naxsi,$(NGINX_HTTP_NAXSI_MODULE_SOURCE))
+NGINX_POST_EXTRACT_HOOKS += NGINX_NAXSI_EXTRACT
+NGINX_CONF_OPTS += $(addprefix --add-module=,$(call qstrip,$(@D)/naxsi-$(NGINX_HTTP_NAXSI_MODULE_VERSION)/naxsi_src))
+endif
+
 ifeq ($(BR2_PACKAGE_NGINX_HTTP_REWRITE_MODULE),y)
 NGINX_DEPENDENCIES += pcre
 else
@@ -241,6 +249,12 @@ define NGINX_DISABLE_WERROR
 	$(SED) 's/-Werror//g' -i $(@D)/auto/cc/*
 endef
 
+define NGINX_NAXSI_EXTRACT
+	$(call suitable-extractor,$(notdir $(NGINX_EXTRA_DOWNLOADS))) \
+		$(DL_DIR)/$(notdir $(NGINX_EXTRA_DOWNLOADS)) | \
+		$(TAR) -C $(@D) $(TAR_OPTIONS) -
+endef
+
 NGINX_PRE_CONFIGURE_HOOKS += NGINX_DISABLE_WERROR
 
 define NGINX_CONFIGURE_CMDS
-- 
2.7.4

[Buildroot] [PATCH 1/1] package/nginx: Add naxsi module option.

[Thomas Petazzoni]

Hello,

On Mon, 11 Jul 2016 13:56:16 -0400, Adam Duskett wrote:
> Naxsi is a third party nginx module reads a small subset of simple rules
> containing a list of known patterns involved in website vulnerabilities.
> This module behaves like a DROP-by-default firewall for nginx.
> 
> The reason for the changes to the make file was because naxsi is listed
> on github, and even though there is a option to specify a url for a 3rd party
> module, this option only seems to work for a local file url.  As such
> a EXTRA_DOWNLOADS and POST_EXTRACT_HOOKS was added to the makefile
> so that the module is first downloaded and then extracted into the
> nginx source directory, and then the module source is added to the
> config options.  This was the cleanest solution I could find, if anybody
> thinks of a cleaner solution please let me know.
> 
> The hash for the module was also added to nginx.hash.
> 
> Signed-off-by: Adam Duskett <aduskett@codeblue.com>

Thanks for this patch. I had a look at this nginx thing, and indeed
building third-party modules is annoying, as they can only be built as
part of the nginx build process. I.e you cannot build nginx, and then
later on build additional third-party extensions.

However, I don't like the approach taken in your patch. I would instead
prefer if you could do something like this:

 * A separate nginx-naxsi package, which just downloads and extracts
   the source code of the third party module. It should be like 4 lines
   of code, using the generic-package infrastructure.

 * Then, in nginx.mk, if BR2_PACKAGE_NGINX_NAXSI is enabled, you add a
   dependency on it, and add a pre-configure hook that creates a
   symbolic link from the appropriate location in the nginx source tree
   to the directory where nginx-naxsi was extracted.

Could you try something like this?

It is worth mentioning that since nginx 1.9.1, they have added the
possibility of building modules as shared objects that are loaded at
runtime, and they are planning in the future to allow third party
modules to be built separately from nginx itself. See
https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/:

"""
In future releases, we plan to add the ability to compile modules after
the NGINX binary has been compiled.
"""

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] package/nginx: Add naxsi module option.

[Adam Duskett]

Hello,

On Mon, 11 Jul 2016 13:56:16 -0400, Adam Duskett wrote:
> Naxsi is a third party nginx module reads a small subset of simple rules
> containing a list of known patterns involved in website vulnerabilities.
> This module behaves like a DROP-by-default firewall for nginx.
>
> The reason for the changes to the make file was because naxsi is listed
> on github, and even though there is a option to specify a url for a 3rd party
> module, this option only seems to work for a local file url.  As such
> a EXTRA_DOWNLOADS and POST_EXTRACT_HOOKS was added to the makefile
> so that the module is first downloaded and then extracted into the
> nginx source directory, and then the module source is added to the
> config options.  This was the cleanest solution I could find, if anybody
> thinks of a cleaner solution please let me know.
>
> The hash for the module was also added to nginx.hash.
>
> Signed-off-by: Adam Duskett <aduskett@codeblue.com>

> Thanks for this patch. I had a look at this nginx thing, and indeed
> building third-party modules is annoying, as they can only be built as
> part of the nginx build process. I.e you cannot build nginx, and then
> later on build additional third-party extensions.

Agreed; I am glad this will be fixed in the future.

> However, I don't like the approach taken in your patch. I would instead
> prefer if you could do something like this:

> * A separate nginx-naxsi package, which just downloads and extracts
>   the source code of the third party module. It should be like 4 lines
>   of code, using the generic-package infrastructure.

I discussed this with Yani before hand and the reason I submitted it
like this is because
we thought that perhaps it would be a bit.... cluttering if we had a
separate package for each
new module.

> * Then, in nginx.mk, if BR2_PACKAGE_NGINX_NAXSI is enabled, you add a
>   dependency on it, and add a pre-configure hook that creates a
>   symbolic link from the appropriate location in the nginx source tree
>   to the directory where nginx-naxsi was extracted.

By all means I absolutely can.  Again, are you sure it won't be too
much clutter?


> Could you try something like this?

> It is worth mentioning that since nginx 1.9.1, they have added the
> possibility of building modules as shared objects that are loaded at
> runtime, and they are planning in the future to allow third party
> modules to be built separately from nginx itself. See
> https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/:

That will be fantastic once a lot more 3rd party modules are updated
to include independent
building!

> """
> In future releases, we plan to add the ability to compile modules after
> the NGINX binary has been compiled.
> """

Fantastic news!


Adam


On Tue, Jul 12, 2016 at 10:33 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 11 Jul 2016 13:56:16 -0400, Adam Duskett wrote:
>> Naxsi is a third party nginx module reads a small subset of simple rules
>> containing a list of known patterns involved in website vulnerabilities.
>> This module behaves like a DROP-by-default firewall for nginx.
>>
>> The reason for the changes to the make file was because naxsi is listed
>> on github, and even though there is a option to specify a url for a 3rd party
>> module, this option only seems to work for a local file url.  As such
>> a EXTRA_DOWNLOADS and POST_EXTRACT_HOOKS was added to the makefile
>> so that the module is first downloaded and then extracted into the
>> nginx source directory, and then the module source is added to the
>> config options.  This was the cleanest solution I could find, if anybody
>> thinks of a cleaner solution please let me know.
>>
>> The hash for the module was also added to nginx.hash.
>>
>> Signed-off-by: Adam Duskett <aduskett@codeblue.com>
>
> Thanks for this patch. I had a look at this nginx thing, and indeed
> building third-party modules is annoying, as they can only be built as
> part of the nginx build process. I.e you cannot build nginx, and then
> later on build additional third-party extensions.
>
> However, I don't like the approach taken in your patch. I would instead
> prefer if you could do something like this:
>
>  * A separate nginx-naxsi package, which just downloads and extracts
>    the source code of the third party module. It should be like 4 lines
>    of code, using the generic-package infrastructure.
>
>  * Then, in nginx.mk, if BR2_PACKAGE_NGINX_NAXSI is enabled, you add a
>    dependency on it, and add a pre-configure hook that creates a
>    symbolic link from the appropriate location in the nginx source tree
>    to the directory where nginx-naxsi was extracted.
>
> Could you try something like this?
>
> It is worth mentioning that since nginx 1.9.1, they have added the
> possibility of building modules as shared objects that are loaded at
> runtime, and they are planning in the future to allow third party
> modules to be built separately from nginx itself. See
> https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/:
>
> """
> In future releases, we plan to add the ability to compile modules after
> the NGINX binary has been compiled.
> """
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH 1/1] package/nginx: Add naxsi module option.

[Thomas Petazzoni]

Hello,

On Tue, 12 Jul 2016 11:08:31 -0400, Adam Duskett wrote:

> > Thanks for this patch. I had a look at this nginx thing, and indeed
> > building third-party modules is annoying, as they can only be built as
> > part of the nginx build process. I.e you cannot build nginx, and then
> > later on build additional third-party extensions.  
> 
> Agreed; I am glad this will be fixed in the future.

Me too :)


> I discussed this with Yani before hand and the reason I submitted it
> like this is because
> we thought that perhaps it would be a bit.... cluttering if we had a
> separate package for each
> new module.
> 
> > * Then, in nginx.mk, if BR2_PACKAGE_NGINX_NAXSI is enabled, you add a
> >   dependency on it, and add a pre-configure hook that creates a
> >   symbolic link from the appropriate location in the nginx source tree
> >   to the directory where nginx-naxsi was extracted.  
> 
> By all means I absolutely can.  Again, are you sure it won't be too
> much clutter?

I don't think so, especially when in the future they plan to add the
possibility of building third-party modules separately. When this will
be possible, we will definitely want to take advantage of this
feature, which means we'll have one Buildroot package per nginx
third-party module.

So we can just as well start today by having separate packages per
nginx third-party module, even if today they do not really build "on
their own".

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com