Skip to main content


Linux really needs to remove the “privileged ports” security theater bullshit.

We’re no longer living in the mainframe era. The security properties of the Internet are different to mainframes. This is actually an anti-feature that either complicates life or actually compromises security (when folks run servers as root and forget to drop privileges , etc.).

If anyone has any sway within the kernel team, etc., please do your thing.

source.small-tech.org/site.js/…

#linux #security #theatre #networking

in reply to Aral Balkan

Bloody autocorrect got me with the American spelling of the word in the end. I knew it would one day :)
in reply to Aral Balkan

after Brexit, Johnson's win at the GE and all the shenanigans that followed pushed me to leave the UK, I made a point of using the American spelling everywhere I can.

I know it sounds silly, but imagine if I go back to the UK and keep doing it :D

in reply to Aral Balkan

Perhaps it is not about mainframes, but multi-user systems? Sudo (and its group) is supposed to make life easier on multi-user systems..
in reply to Aral Balkan

how is it theatre? For example when I have to expose ssh to the internet I usually use port 2022 because at least that's one more layer of security, in case someone gets user access to the system and are able to crash the ssh service they can't start their own service that harvests passwords because it was on a privileged port.
in reply to Aral Balkan

ok I read the post but all I can say is that I deploy services of all sorts of languages and frameworks for a living and I never have to give them any higher privileges. Because in production there is always a proxy in front of the service, and in dev they can use nonstandard ports.

So I still see no reason to allow services to use privileged ports in my view. But we all have different perspectives.

in reply to Stefan Midjich ꙮ҄

@stemid This is my use case: ar.al/2020/08/07/what-is-the-s…

We need to set up your own Facebook on your own server in under a minute with no technical knowledge required on your part. And democratise development while we’re at it as much as possible. So no front controller/proxy, etc., setups. Think lightweight server with in-process database.

But, beyond use cases, again, it provides no real security unless you’re administering a System/360.

in reply to Aral Balkan

@stemid I mean, there's just plenty of solutions. From what I read in your article you have found one through modifying a kernel parameter. Which means that the mechanism is implemented. It's just not enabled by default.

I see lots of workarounds to your problem and Linux in itself doesn't prevent one from achieving the behavior you're looking for.

in reply to paillp

@paillp @stemid Yes and those workarounds complicate workflows and create usability issues.
in reply to Aral Balkan

This is just about cap config

`sudo setcap 'cap_net_bind_service=+ep' /usr/bin/nc`

in reply to paillp

@paillp Please see the linked page (and the articles linked to that) :)
in reply to Aral Balkan

stopped reading the article after "And this does not work if the daemon is written in Java, which is quite popular for web servers."
in reply to yin yang yoink

@oreolek I’m trying to simplify things, not complicate them :)

ar.al/2020/08/07/what-is-the-s…

Unknown parent

Aral Balkan
@demvw Just = the only reason you need sudo during an installation process. These things have usability ramifications.
in reply to Aral Balkan

It isn't security theatre in our case, where we have thousands of shell users and the user/root boundary is the most essential security feature.
in reply to maswan

@maswan That’s cool but it’s also an edge case today. So having that as a feature you can turn on, versus one that nearly everyone else has to turn off (or work around) would make much more sense.
in reply to Aral Balkan

Maybe, but I'm not convinced from your links that it is such an odd edge case even among places that just runs a handful of services per VM in regards to horizontal traversal.