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

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

On 2021-09-05 12:23 +0200 (Sun), Christian Horn wrote:

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

I'm not clear on what you mean by saying  that for low-traffic sites
"static site generation is probably just overhead," if that's indeed what
you're saying. But if it's anything along the lines of "smaller sites don't
need this," that's wrong. The biggest benefit of static site generation is
low maintenance overhead, which small sites need even more than bigger
ones. (I have a site I built more than fifteen years ago that I now see
could have been statically generated, but is not. And that's now hurting me
when it comes to moving it to different hosting.)

> "don't advertise containers for security" or something along the
> lines is just a generic theme I got from discussions with colleagues.

Well, I would say that's wrong.

> Sounded like the security benefit is assumed to be above zero, but
> not as big as from i.e. SELinux with properly written policies.

That's absoutely, unequivocially *dead* wrong, in my experience. I've
written and audited SELinux security policies and I'll take a Docker
container any day. As opposed to SELinux rules, in a container it's just
way, *way* easier to control the exposed surface and interactions with
other part of the system while at the same time keep something running
properly.

Keep in mind that with SELinux you need to understand and handle _every_
access to anything that the program makes. As one example:

Does the program try to read files? On a shared system you need to
understand what it's trying to read, what else other
programs/users/whatever might have placed there or might place there in the
future, and what the risks of letting it read those things are. In a
container, there are no other users or other programs so it's just reading
whatever is there in any standard install of that OS. Which one sounds like
less thinking to you?

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

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