potential for priv esc

[BenGardiner]

https://github.com/reap3r/firewall/blob/master/appliance/app/rules_scheduler.py#L8

This is a TODO for us (I'll take the TODO for now). The ufw rules sched is running as root and reading/parsing data set by the lower priv service. The following question needs to be answered in affirmative to have confidence in this: does ufw.run protect against command injection?

[callrbx]

Technically, no. If malicious commands somehow ended up in the rules DB I believe they would be executed as root. This is a huge issue, and I am tracking it.

However, the IP filtering currently only allows valid IP addresses to be given. We probably need to add a filter in the rules scheduler itself, or do a deeper dive into ufw.run

[BenGardiner]

Ok. Where are you tracking the separate issue of potential exec as root?

[BenGardiner]

ping. is there a filter in the rules scheduler now? are there any guards against command injection in ufw.run ?

you mentioned you were tracking this issue; do you have some notes on the design that mitigate this risk?

[callrbx]

The UFW parser should filter any malicious commands that are manually placed in the DB.
The REST API only accepts valid IP/GEO addresses.

[BenGardiner]

https://github.com/reap3r/nmfta-bouncer/blob/master/appliance/src/rules_scheduler.py#L8

I think there should be more segmentation of privilege here. I'm leary that ufw.frontend.parse_command is impervious to command-injection. i.e. we should mitigate the risk that an attacked who compromises the web front-end and uses it privilege to write to the database to run commands as root.

There might be a way to make the scheduler run as root with dropped privileges so that it can only run ufw, but doing this is non-obvious. I think the biggest bang for the buck here is to require that the ufw scheduler runs in a non-privileged user who has sudo rights only for /usr/sbin/ufw

cc @krishnaswin