允许特定的Linux用户绑定到端口443 [英] Allow specific linux user to bind to port 443

问题描述

我负责设置一个运行在SSL之上的JBoss Web应用程序，因此应该可以通过端口443对其进行访问.

当然，它可以由具有root特权的用户启动，但这是我要避免的事情.我想由非特权用户运行它，以便我可以严格控制此应用程序执行的所有操作，并且不提供超出所需的访问权限.

但是，问题是非特权用户无法绑定到< 1024端口.我知道为什么是设计使然，但是，这种安全性原则不允许我在JBoss应用程序中实践良好的安全性.

解决此问题的最佳方法是什么?我当然想避免使用丑陋的解决方案，例如绑定到端口8443.

解决方案

1.

编写使用特权端口的网络服务的常用方法是:

• 以root用户身份启动服务；
• 创建套接字并将其绑定到特权端口；
• 通过切换到非特权用户来放弃root特权:
  • 使用 setuid(2) 不可撤销地放弃特权；
  • 使用 seteuid(2) 放弃特权，但仍然可以切换回root.

2.

允许非特权用户启动特权服务的常用方法是设置setuid bit.

绑定到特权端口后，服务可以切换回real user id(启动服务的用户)或某些特殊用户(例如cron守护程序的cron用户).

3.

另一个(特定于Linux的)选项是在不提供完全root特权的情况下为您的服务提供CAP_NET_BIND_SERVICE功能.

这可以直接使用libpcap在代码中完成(但是您仍然需要setuid bit)，或者如果文件系统支持，可以通过将功能位附加到可执行文件上(因此不需要setuid bit). /p>

I am in charge of setting up a JBoss web application that runs over SSL, thus should be accessible over port 443.

Of course, it can be started up by user with root privileges, but that is something I'd like to avoid. I'd like to run it by non-privileged user so I can strictly control everything this application does and give no more access than needed.

However, the problem is that non-privileged users can not bind to <1024 ports. I am aware of the reasons why this is so by design, however, this security principle does not let me to practice good security with my JBoss application.

What is the best way to solve this? I'd certainly like to avoid an ugly solution like binding to port 8443 instead.

解决方案

1.

Common approach to write network services that use privileged ports is:

• start service as root;
• create socket and bind it to privileged port;
• drop root privileges by switching to unprivileged user:
  • use setuid(2) to drop privileges irreversibly;
  • use seteuid(2) to drop privileges but remain able to switch back to root.

2.

Common approach to allow unprivileged users to start privileged service is to set setuid bit.

After binding to privileged port, service can switch back to real user id (user that started your service) or some special user (like cron user for cron daemon).

3.

Another (linux-specific) option is to give your service CAP_NET_BIND_SERVICE capability without giving full root privileges.

This can be done directly in code using libpcap (but you still need setuid bit), or by attaching capability bit to executable, if your filesystem supports it (thus you don't need setuid bit).

这篇关于允许特定的Linux用户绑定到端口443的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！