Question about Luci and non-privileged users

I have posted this question elsewhere mixed in with other somewhat related questions:

(SSH security question)

([SOLVED] VLAN isolation and router access questions)

but it remained the only question not addressed specifically. I suspect that is because so few want to do what I am trying to do.

As per the guidelines of @jeff ([SOLVED] VLAN isolation and router access questions), I set up a non-privileged user following the instructions here under 'Create a non-privileged user in OpenWrt', with 'Method 1' for access:

https://openwrt.org/docs/guide-user/security/secure.access

this all worked flawlessly. I can SSH in as the new non-privileged user, and use sudo to make changes.

My question is related to the fact that I do most of my setup and changes via Luci. I don't have the skills yet to be able to do everything in CLI, and I am better visually with a GUI right now. So, my goal is to log in to Luci as a non-privileged user, but still be able to make the necessary changes. This would then enable me to do the next step recommended by @jeff, which is disable the root login.

To me, what I want to do seems impossible because I can't see any way a non-privileged user would be able to make changes with no way to sudo via the GUI. I can't even figure out any way to grant the new non-privileged user access via Luci. I did endless searches on this and found nothing at all. I did, though, come upon this long-running project, so it seems I am not the only one interested in this.

(https://github.com/openwrt/luci/issues/623)

(https://github.com/Hostle/openwrt-luci-multi-user)

(https://forum.archive.openwrt.org/viewtopic.php?id=54593)

All I am trying to do is restrict access to Luci to a non-privileged user that can make changes, and be able to implement this in a simple manner i.e. have the same type of approach that is being done with SSH. It seems to me there is little security improvement to have set up SSH to only access via a non-privileged user with sudo if I leave the root login enabled and Luci can still have access via the root alogin. I also realized that disabling the root login would cut off my access to Luci as it is configured right now. I saw a warning on this on the ArchLinux wiki here (scroll to 'Disable root login'):

(https://wiki.archlinux.org/index.php/sudo)

This seems to apply if I used any of the listed commands as my means of disabling the root login (I'd be curious to hear what the suggested method is to disable the root login with OpenWrt) and if I use 'Method 1' for access, as I mentioned above I did. So, I want to make sure I don't cut off access to Luci unless I can find a way to accomplish what I am trying to do.

Any help would be great, but I am not holding out high hopes for this because it doesn't seem like it's doable.

I was just thinking about a possible (but perhaps cumbersome) workaround that I could use until a better solution is found, and was hoping someone could comment on this, or suggest a better alternative. Could I disable the root login, and then if I wanted to use Luci just SSH in as described above, re-enable the root login, make my changes, and then disable the root login again? I won't need Luci access that often, and this would accomplish my goals. I have a dedicated computer that I only use for OpenWrt access, only offline, and only via a wired connection to a dedicated VLAN port that is only for this purpose. I'm just trying to come up with any way to reduce the attack surface and still be able to use the Luci interface...

I'm not entirely sure what you are trying to accomplish. Unless your non-privileged user is a) not you, and b) supposed to do something on the router without access to everything, all you are doing is adding another layer of passwords. In which case I'm inclined to suggest just choosing a significantly stronger password for the root user.

2 Likes

There's a thought experiment that might help here

  • LuCI (as well as the APIs that have similar function) needa super-user privilege to be able to modify your system
  • As a result it needs to run as UID 0, whatever you want to call it

So you can:

  • Give it that privilege when it starts to run and require authentication to access it
  • Modify it completely to request privilege every time it needs to, which means it pretty much still has it all the time (suid binaries have their own security risks)
  • Not run it at all

Whether that authentication is using the password from a user with 0:0, or another one, or a different authentication scheme, it doesn't matter. The process still gets those credentials to access your system.

2 Likes

@takimata Thanks for the comment. I guess what I was trying to do was not run as root since everything I've read for any Linux system says to never do that. I'm not a Linux expert by any means, I'm likely not even an amateur, but for example I have a Debian box and I've never logged in as root even one time. So far I've been able to do everything via su (which I opted to do instead of the more usual sudo). So based on @jeff suggesting creating a non-privileged user login and using that with sudo for SSH, I was just trying to follow those guidelines. The issue came about when trying to figure out how to use Luci without running as root. I think the best bet is to just make sure I have a very secure password and leave it at that.

1 Like

Thanks Jeff, that gives me some more clarity.

I realize this is old, but I stumbled upon this while googling.

My solution:

  • disable the web ui, LUCI, from external access (bind uhtppd to 127.0.0.1)
  • create a non privileged user with sudo and ssh access
  • harden the ssh access (no root login, no password login, only ssh key access)
  • ssh to the router and forward the LUCI port 80
  • access LUCI from via the forwarded port (logging into LUCI as root)

With the above setup, only my privileged user can access the LUCI interface, via an SSH port forward.

2 Likes

Thanks @codyzu. I was reading about some of this here:

https://openwrt.org/docs/guide-user/luci/luci.secure

I am still uncertain about a few steps, but I will keep working on it and if I have trouble I'll ask in here.

1 Like