Mailing List Archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Mon, Aug 30, 2021 at 12:19:44AM +0900, Curt J. Sampson wrote:
> 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.

Yes, below a certain amount of traffic (or extra low latency re-
quirements) that is probably just overhead.

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

"don't advertise containers for security" or something along the
lines is just a generic theme I got from discussions with colleagues.
Sounded like the security benefit is assumed to be above zero, but
not as big as from i.e. SELinux with properly written policies.

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

This thread here got me into trying out and containers for the first
time for my own selfhost purposes.

Home | Main Index | Thread Index