Hi @Fotis_Greece,

same problem with Pharos APs here: https://community.tp-link.com/en/business/forum/topic/168326

@forrest, please see my post in the Wireless Boradband forum for my suggestions about how to add Privilege Separation without breaking existing functionality. In my opinion, it makes no sense to give people ssh access to the EAPs and Pharos devices while breaking the ability to use certain commands such as ping or radartool. Please have R&D fix this in next firmware.

In my post regarding Pharos firmware I show you a very easy way to fix this - use the SUID file attribute (set user-id to file-owner/root) for ping and radartool, that's exactly what it is for in Linux to run commands temporarily as the root user.

Thanks!

forrest wrote

Thank you for your feedback.

For the EAP products, we still don't enable root privilege to the users. Because when we enable root privilege, we can customize the function of EAP and configuration.

When we enable root privilege the devices may meet many abnormal issues, this is not secured for the products.

 

Hello @forrest,

the question is not whether to grant ordinary users root privileges. Of course, ordinary users should not be able to become root, that's what Privilege Separation is all about. The issue is about doing Privilege Separation the right way.

I'm in this discussion with R&D about Privilege Separation since EAP Controller for Linux came out the first time (IIRC it was v2.4.3). Back then EAPC did run all of its program code under root privileges.

This was the reason that EAP Controller could be easily abused to remotely break into the server over the Internet and several Internet servers running EAP Controller had actually been compromised back then by crackers through a well-known Java RMI root exploit. I was the one who reported a proof of concept of this root exploit to TP-Link's R&D and I did even send a full working bug-fix to R&D suggesting to introduce Privilege Separation in EAP Controller only days after EAPC v2.4 was published (just search the forum and mail archives of 2016 to 2018).¹

The goal in Linux is to run any process which interacts with ordinary users (for example the http server/web UI, ssh server, login shell) under an unprivileged user ID, i.e. not root. This prevents bad guys from taking over the device. However, starting httpd, sshd, the login shell, radartool and even ping technically requires root permission:

• httpd needs to run parts of the program code as root to be able to bind to privileged port 80.
• sshd needs to run parts of the program code as root to be able to bind to privileged port 22.
• login needs to run parts of the program code as root to be able to set up the environment for a user.
• ping on EAP needs to run parts of the program code as root in more modern Linux kernels.
• radartool on CPE/WBS needs to run parts of the program code as root, probably to get access to the WiFi chip registers.

The solution to run only parts of program code as root without granting the user full root access is the so-called SUID bit together with a programmatically release of root privileges (through the setuid system call) when privileges are no longer required. This functionality is present in every Linux system since first version.

The SUID bit and the setuid system call have been introduced in UNIX 7th edition which was released back in 1979. So it's now a 40-years old technique, which is directly related to Privilege Separation, since the SUID bit was needed to allow implemetation of Privilege Separation at all.

Please don't get me wrong:

I welcome introduction of Privilege Separation in EAP and Pharos firmware very much! It is the right step in order to increase system security.

But it should not break existing functionality such as the user being able to run ping on EAP devices or radartool on Pharos devices. Also, it is very easy to fix this and to allow ping and radartool for non-root users without the need to grant full root access to them. Just set the SUID bit and root as the owner on both executables.

__________________

¹ BTW: even Omada Controller 3.2.1 still has root-owned files which have read permissions for ordinary users. Albeit the controller uses Privilege Separation for its start, it doesn't use this technique to its full extend when it comes to access files. For example, every ordinary user having an account on the server running Omada Controller can read the keystore password for the TP-Link SSL certificate in Omada Controller's properties. Albeit not a critical bug, I always fix those file permissions in the Omada Controller community version for Linux, which doesn't grant access to sensitive files for ordinary users.