What's new

Allow Non-Root User to Bind to Lower Ports < 1024?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

garycnew

Senior Member
How does one allow a Non-Root User to Bind to Lower Ports < 1024 in Asuswrt-Merlin? Thank You.
 
Just a random guess, no idea if it would work:

Install libcap-bin and use something like setcap cap_net_bind_service=ep myexeprog
 
Just a random guess, no idea if it would work:

Install libcap-bin and use something like setcap cap_net_bind_service=ep myexeprog

Colin,

I receive "Failed to set capabilities on file" and "Operation not supported" errors attempting to use setcap.

Code:
# opkg install libcap-bin
Installing libcap-bin (2.63-1) to root...
Downloading https://bin.entware.net/armv7sf-k2.6/libcap-bin_2.63-1_armv7-2.6.ipk
Configuring libcap-bin.

# opkg list-installed | grep -i libcap
libcap - 2.63-1
libcap-bin - 2.63-1

# opkg files libcap-bin
Package libcap-bin (2.63-1) is installed on root and has the following files:
/opt/sbin/capsh
/opt/sbin/setcap
/opt/sbin/getpcaps
/opt/sbin/getcap

# setcap cap_net_bind_service=ep /opt/bin/proxy
Failed to set capabilities on file '/opt/bin/proxy': Operation not supported

# getcap /opt/bin/proxy
#

A cursory search of the errors does not yield much.

Thanks, again, for your assistance.

Respectfully,


Gary
 
@ColinTaylor

I noticed some references to authbind as an alternative. However, it doesn't appear to be packaged within OpenWRT or Entware. I'd have to roll my own to test.

The last alternative I can think of is to give the application in question root access.

Any additional thoughts on the subject?

Thanks.


Gary
 
Last edited:
I'm not really surprised that setcap didn't work. It probably needs the kernel to be compiled with some option enabled.

I was wondering why you weren't running it as root as that's the way almost everything runs by default. There are a couple of processes that spawn a non-root child process for security but most don't.
 
I'm not really surprised that setcap didn't work. It probably needs the kernel to be compiled with some option enabled.

I was wondering why you weren't running it as root as that's the way almost everything runs by default. There are a couple of processes that spawn a non-root child process for security but most don't.

@ColinTaylor

Security was the primary concern.

It seems functionality trumps security with Asuswrt.

As always, I appreciate your input.

Respectfully,


Gary
 
It seems functionality trumps security with Asuswrt.
Well at the risk of sounding like a broken record, Asuswrt is not a Linux distro. It's hardly surprising some features aren't enabled. The objective of Asuswrt is to be as lean as possible and not waste resource by enabling unused/unsupported features. Personally I wouldn't expose any router services to the internet other than OpenVPN. If I wanted to run a public facing service I'd put it on a "proper" machine and not my internet gateway/firewall device. /2cents
 
Well at the risk of sounding like a broken record, Asuswrt is not a Linux distro. It's hardly surprising some features aren't enabled. The objective of Asuswrt is to be as lean as possible and not waste resource by enabling unused/unsupported features. Personally I wouldn't expose any router services to the internet other than OpenVPN. If I wanted to run a public facing service I'd put it on a "proper" machine and not my internet gateway/firewall device. /2cents

The services in question are run on AiMesh Nodes within the private network.
 
Does setting the set uid on exec not work or is that too wide an attack surface for your needs?
I suppose that would be a compromise to running the application as root. The preference would be to allow non-root binding to lower ports < 1024, but that doesn't seem plausible under Asuswrt.
 
I suppose that would be a compromise to running the application as root. The preference would be to allow non-root binding to lower ports < 1024, but that doesn't seem plausible under Asuswrt.
I must admit I haven't worked with this kind of approach, the Linux package I maintain is run as root so I haven't needed to worry about this stuff.

So I don't know about how to drop privileges after doing the privileged things you need to do, if it means a lot to you it's probably worth doing a bit of searching on this topic before giving up.
 
I must admit I haven't worked with this kind of approach, the Linux package I maintain is run as root so I haven't needed to worry about this stuff.

So I don't know about how to drop privileges after doing the privileged things you need to do, if it means a lot to you it's probably worth doing a bit of searching on this topic before giving up.
It doesn't look too hard to do:
 
I believe port-forwarding might be the alternative workaround I've been searching for.

Thanks @ColinTaylor and @raven-au for your input.

Respectfully,


Gary
 
Not being able to bind a non-root service to a privileged port (< 1024) is a security feature of Linux (and possibly other *IX). It ensures that a regular users cannot run a rogue service like an SMTP server or a web server on a standard port.
 
@RMerlin

It seems there is quite the debate in the kernel world around the premise of this "security feature." I understand both sides of the debate and don't really have a strong opinion one way or the other on the matter.

I was simply trying to discern an answer with regard to its implementation and subjectiveness within Asuswrt, which you and others have confirmed.

I appreciate all that you do in the development and maintenance of one of the best wireless router platforms on the market and for weighing in on such a trivial question.

Thank You!

Respectfully,


Gary
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top