Re: [tlug] Dealing with software with wide attack surface

[Michael Paddon <michael@example.com>]

On 2021-08-29 04:32, Jens John wrote:
> On Sat, Aug 28, 2021 at 02:58:19PM +0200, Christian Horn wrote:
> > I am wondering how you deal with software with a big
> > attack surface, or to which degree you care.
>
> Containment and resource restraints, lastly offline backups of the 
> persistence
> layer.
>
> For which you should be making use of all possible modern Linux 
> security
> features, which is often overlooked even and especially by major 
> distributions
> which ship systemd .service files for apache, nginx etc that are not
> particularly hardened.
>
>   - you should use a Linux distribution with MAC set up properly, which 
> means
>     Ubuntu/$Derivative and AppArmor or RHEL/Fedora/$Derivative and 
> SELinux. Of
>     course, SELinux should be in enforcing mode and labels assigned 
> correctly as
>     to deny nginx to write to anything it shouldn't write to.
>
>   - you should be using systemd and its containment features even with 
> nginx,
>     apache etc provided by the main OS. When you use systemd properly 
> and its
>     capabilities to contain and restrain processes, separate container 
> runtimes
>     are obsolete and KVM level isolation almost overkill (for maximum 
> security,
>     by all means, add micro VMs on top).
>
>     People CANNOT WRITE sysvinit scripts that even come close to 
> covering the
>     same array of control without VERY deep knowledge and they will 
> likely get
>     it wrong anyway. Use systemd, and use it correctly.
>
>
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
>     https://www.freedesktop.org/software/systemd/man/systemd.exec.html
>
>     For example:
>
>     Install nginx, configure it to serve your webstuff, then enter
>
>       systemctl edit nginx.service
>
>     and add settings like (demonstration ONLY):
>
>     [Service]
>     # Allow executing nginx as non-root while still being able to bind 
> to
>     # privileged ports 80 and 443. On Ubuntu-like systems, nginx runs 
> as root
>     # with privdropped worker processes. Completely unnecessary.
>     User=www-data
>     Group=www-data
>     AmbientCapabilities=CAP_NET_BIND_SERVICE
>     NoNewPrivileges=yes
>     MemoryMax=1G
>     PrivateDevices=yes
>     ProtectSystem=strict
>     ProtectHome=yes
>     ProtectKernelTunables=yes
>     ProtectControlGroups=yes
>     # Has to write logs, so whitelist this path
>     ReadWritePaths=/var/log/nginx
>     # Will not be able to write to UNIX sockets
>     RestrictAddressFamilies=AF_INET AF_INET6
>
>     and many more settings are possible; you can even control the 
> amount of
>     bandwidth and CPU the webserver can take.
>
> The aforementioned features alone, which are easy to configure and easy 
> to learn
> by spending time with the systemd manpages, should easily cover 99.99% 
> of attack
> surface on dynamic components.
>
> Of course, in the end, you will have a persistence layer somewhere, a 
> database
> server or a directory hierarchy with user-generated content. This type 
> of stuff
> needs to be shipped off of the online system to a backup location that 
> is
> write-only excluding overwrites from the source system or completely
> disconnected, like offline backups. Because in the end, no security is 
> 100%.

This is good advice. More formally, you should try to implement a 
"reference monitor".

Jaegar (2011) describes the concept as "a system component, called a 
reference validation mechanism, will be responsible for enforcing the 
system’s access control policy over user process operations. The 
reference monitor concept defines the requirements for implementing such 
a mechanism in a manner that ensures that malicious users cannot 
circumvent policy enforcement."

There's a good discussion here on why this pattern is helpful. 
https://www.mdpi.com/2078-2489/7/2/23/pdf