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

["Curt J. Sampson" <cjs@example.com>]

On 2021-08-28 14:58 +0200 (Sat), Christian Horn wrote:

> I am wondering how you deal with software with a big
> attack surface, or to which degree you care.

Well, ideally I simply don't use it. You're wanting a web site: those
should be statically generated to the greatest degree possible. If you can
do this, you mostly don't even have your own servers serving any
information to the general public. That said, I'm guessing this is an
option that is too much work for you to pursue in this case, so I'll
continue on with some of the other stuff being discussed here.

>   - a container.  Means I need no extra KVM instance, but 
>     container separation is not meant to be for security.

I'm not sure where you got this idea, but it's basically dead wrong. In
_theory_ you can get more security from a VM than a container, but in
practice you will not because few people care to take the effort to set up
stand-alone machines that actually have the minimal set of software loaded
for a particular application. Containers go to the level of not just
removing things like systemd, but even removing /sbin/init.

And removing all the users and any protection between them, too, of course.
Because if everything is running as root, there's no such thing as a "root
exploit" (a privilege escalation), right? This sounds like an amusing
quip, but it's actually quite serious. If there's something an attacker who
took control of your program can do as root that he ought not be able to
do, you have things in your container that ought not be there!

These days I would _never_ run a web server (or pretty much any Internet
server) directly in a VM; I'd always containerize it. This also happens to
make testing/staging/etc. a lot easier as well.

On 2021-08-28 21:32 +0200 (Sat), Jens John wrote:

>   - 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.

Yeah, this is just a complete nightmare and, having audited SELinux
configurations, I wouldn't trust them as far as I can throw them. Use a
container.

It's just way, _way_ easier to say "have access to everything because there
are no other programs on this system" than to try and figure out which
individual files a program should be able to access and make sure you're
removing access from other stuff as things change.

I should mention that what containerisation does is not new to me, and I
was working towards such things as best I could long before containers
became a thing in Linux. Back in the early 2000s I would never, ever start
an application server as root (not for web server, not for DB servers) and
I would never share a web or DB server between two applications. Each
application had its own set of servers started as a normal user (each
application had a separate user) and a front-end proxy server would take
care of distributing requests to the applications on a machine. (And this
did hugely help with testing, as well, since a developer could start the
three web servers and two DB servers on his own machine--several
simultaneous instances if necessary--to test out what was going to happen
at release.)

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch