Hacker News Reader

Comment by wang_li | Hacker News Reader

>As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially

Which is why what we really need is the ability to set properties on each network port and have those persist across reboots.

Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address.

Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks.

View on HN

> Which is why what we really need is the ability to set properties on each network port and have those persist across reboots.

SELinux can effectively do this via the 'semanage port' options[1] -- so you could configure it and then set privileged ports to 0 and achieve what you're looking for.

Admittedly this seems like using a crane and wrecking ball to hang a painting.

[1]: https://www.man7.org/linux/man-pages/man8/semanage-port.8.ht...

I think you're overstating the additional complexity, just a little.

SELinux on CentOS 7+ is basically turnkey. If you’re turning it off you’re doing yourself a disservice.

Can't agree more.

> Admittedly this seems like using a crane and wrecking ball to hang a painting

Precisely. SELinux is incredibly complicated. It would be nice to have something simpler.

Anything you invent that can confine software from the outside will become SELinux. SELinux is actually really simple, you tag stuff and write rules about what tags can and can’t do to other tags. And writing your own policies, while strange and esoteric because it uses m4, is straightforward.

SELinix is hard because you really have to know what’s going on with your software to actually write these policies. The complexity is in creating a maintainable system of tags and rules with software that does all kinds of crazy weird things.

The complexity is irreducible. The only thing you can really do is create tools to handle common cases and that’s semanage.

I disagree that the complexity is irreducible. SELinux really complicates things by having compiled policies that have their own tool chain, and (although this is definitely debatable) using file system labelling versus just paths (like AppArmor for example). I know there are shortcomings for paths versus labels, but administrators are much more used to working with paths and simple config file, versus labels and compiled policies written in a DSL. In addition, the auditing system for understanding what SELinux is actually doing is complicated, so much so that there’s additional tools around it that allow you to pipe the logs into so you can get something resembling a human explanation for what’s going on.

None of this is irreducible. SELinux does itself no favours by having a complicated tool chain with a terrible user experience. And I say this as someone who always leaves SELinux enabled…

I think we’re maybe mostly agreeing. I’m not going to sit here and defend SELinux’s toolchain or audit messages — they’re weird as fuck.

My only point is that once you get over the oddities of toolchain, the DSL, the odd smattering of tools unconnected tools and learn to read the audit messages (no simple task mind you. It’s stupid and shouldn’t be so hard) only then do you hit the real complexity which is actually knowing enough about the software internals and the deep kernel and userspace magics to write intelligible policies. SELinux could go a long long way on making the easy stuff easier and more friendly, but once you go down the rabbit hole it’s all the same.

It really can be as simple as deploying your service to a clean system, then grepping the audit log and choosing whether or not you're comfortable feeding that to audit2allow

More often than not you probably are in this clean room situation, but that doesn't mean ignore all reason

Follow things like the FHS and the CIS benchmark. Don't put your application data in /etc/. Don't expect to execute things in /tmp/.

It's guard rails for things you should be doing, the policies come from what the industry has determined are reasonable defaults.

I understand it's foreign to people but disabling it is silly. It's easy to do it this way, admittedly 'poorly', and still gleam some benefit.

True, at the end of the day there is still a huge amount of work to be done modelling the access your application needs. But I do think that can be conceptually simple, and all the horridness of the SELinux toolchain makes it far more scary than it needs to be.

That being said, I feel like like with containers and a generic SELinux/AppArmor policy that restricts the containerized app, there's really no need to even bother anymore.

And yet I recall managing launchd security policies to be a fraction of the complexity to manage and easier to verify you were doing the thing you intended. As compared with Android where I observed SELinux required far more man power to maintain / complexity / foot guns.

Now maybe SELinux is indeed more powerful. I’m not well versed enough in that problem domain to do a comparison. In terms of successfully getting broad adoption across teams of various skill sets, I’d say the launchd approach is better holistically.

I thought launchd was more akin to systemd than to selinux or apparmor. Some brief googling didn't show anything about security policies. Do you have a link where I could learn some more?

I don't know that there's anything external and it's possible I may have misremembered. Performance limits are managed in launchd (maximum memory etc). File access security is managed by setting a class on the file via ioctl which controls when the file is accessible (after first unlock, while screen is unlocked, etc).

Maybe there isn't a secondary security layer? Can't recall now but I swear I thought the launchd plist described it all. I don't have a Mac anymore so I can't even look at the plist contents to double-check.

> Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address.

So, regular file permissions for ports. It would be nice if we had 9p's concept of a network filesystem here. No ioctl() needed.

Isn't this provided by inetd and systemd? They bind the socket and hand it to the server, who doesn't need permission to bind any port at all? (with the added optional benefit of "socket activation", i.e. starting the server on-demand when the first connection comes in)

> Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks.

There should be no need for that if you use ambient capabilities. Which you can set in e.g. a systemd unit.

The `authbind` package can automate this by path, user, port and many other things.

It comes from the Debian world (developed by Ian Jackson) so perhaps less well known for RPM users? https://en.wikipedia.org/wiki/Authbind

Reply on news.ycombinator.com