Hi do i disallow certain users from logging in via the Web-UI, e.g. a linux-server admin users reserved for local terminal logins only (ssh)?
Ideally i would like to allow only users in a particular group (like “web” or “minecraft”). How do i do this?
(i am not talking about minecraft servers and their white-lists, but rather the admin webui itself which i like to see better protected.)
System: Ubuntu server 18.04 LTS + mineos-node
The WebUI relies on the underlying OS’s user management, så any limitations you set on the users in your Ubuntu will also be set for your MineOS users. That said, there are no white or blacklists in MineOS itself to hiallow or disallow users.
That’s a pretty big flaw I would say. Is at least root disallowed?
And what can be done to implement such protection? What’s easiest? I noticed some code for group membership checks in auth.js. How can I add a let’s say check for membership of o group defined in the config?
It’s not a flaw–or at least it’s inherent in the design. The authentication component of the webui is simultaneously the least exciting (personally) to work on and also the most intricate part.
As the maintainer of mineos, I’ve created a utility that facilitates action, rather than prohibits it.
Anything you can do with a user such as ‘web’ (that you presumably don’t want to allow to login) already meets these assumptions:
web has a user password set (but why!?)Therefore, web can already log in to ssh and download, create, manage servers. That is, the webui isn’t giving options to users who wouldn’t already have that capability.
Same goes for root. Personally, I don’t set a root password on my hosts. I use sudo. If I tried logging into my host as root in ssh, it would fail. If I tried logging into the webui as root, it would fail.
So, for users who I don’t want to use the webui, I make sure it’s not satisfying those two assumptions above, no code change necessary; and moreover, no arbitrary distinction between users for who may or may not log into the webui.
In short, I opted for trusting the user. Maybe that was the wrong philosophy, but blacklisting (or providing a blacklist functionality) just wasn’t something I valued that highly.
Though untested, I imagine that this would be sufficient along line 30 of webui.js:
auth.authenticate_shadow(username, password, function(authed_user) {
/* add here */
// if (some logic)
// deferred.reject(new Error('some reason'));
/* until here */
if (authed_user)
deferred.resolve({ username: authed_user });
else
deferred.reject(new Error('incorrect password'));
})
Such logic might look like:
var NOT_OK_USERS = ['will', 'bob','root','web'];
if (NOT_OK_USERS.indexOf(username) >= 0)
deferred.reject(new Error('user blacklisted'));
Modify this logic, adding any level of complexity you’re comfortable with.
As flaw in the design is still a flaw, even if intentional. “by design” isn’t an argument I can accept when talking about security. That said…
What I like is a user (with sudo permissions) that can only login via ssh but not through the internet.
So, you are saying the only way to block someone to login is removing the linux password?
I am going to test with public keys. If that works, its fine.
Hmm, this sucks. Sorry.
I would have to use NOPASSWD on sudo and thats incecure too.
Any other proposals how to achieve the above?
…looks like i will try your code examples soon.
I don’t understand your justification.
MineOS’ webui performs functionality as a Linux user, simply put. What functionality is the webui introducing that you consider a flaw–that can’t already be performed by that user already?
root should be passwordless already; if you’re concerned about security, root should never have a password in the first place.
My installations never have root passwords, so my webui deployments never have root access to the webui.
Huh? Under what circumstances would you have to NOPASSWD on sudo? I’m certainly not recommending that.
It’s unclear from the information you’ve provided thus far. Is web or minecraft system accounts? Are they user accounts?
If web is a system account, there’s no password. There’s no login, mission accomplished.
If minecraft is a user account, there potentially is a password, and already that user can log into ssh and do everything that that he’d do in the webui anyway.
I’m saying the way you would block somebody from logging into the webui is removing their password, or making the code change.
Because, as an example, web user. Let’s say it does have a password. So how do you prevent a user from logging into the node via ssh web@somehost? I think in most circumstances, you’ll see /etc/shadow get a ! – which is a password which is not-accepted, and won’t allow login.
So the answer to stopping somebody from using ssh is removing the password.
Perhaps you might counter: but you can lock with password -l web and still use RSA keys. Yes, and comprehensively including additional login methods like RSA keys is a non-trivial code change, a lot of newly-included libraries, and certainly greater than three lines to implement safely and securely. Alternatively, I can not implement RSA keys and let the user copy-paste three lines to disallow a certain user to login. There’s a reason why basically zero other linux services use RSA keys.
In short, it may not be your preference to allow web to log in simply because it doesn’t make sense in the context of MineOS, but that user already can login and run Java and servers (mineos completely aside). The webui simply isn’t stopping what the user can already do via ssh.
If that security model doesn’t gel well with you, that’s what the docker instance is for.
console access.
Me neither, but the only way with this software to take away access to the web-ui for a particular user. E.g. an admin user that has sudo permissions. Yes, they need to keep passwords, but then they are brute-forcable on the web-ui.
I’m not following.
Console access is accessible through three means:
If any of these three are satisfied, then a user has console access. How is the webui giving additional functionality–all functionality is already granted from satisfying any of those three conditions.
The only way to “take away access to the webui for a particular user”
I’m again not following. The way I’ve recommended was a way to take away access by removing a password. The side-effect here is that user would lose option #1 and option #3 access. But they are not given additional functionality, anywhere. You can take away bob’s password, and give him an RSA key, and what you have is a user who cannot log into the webui, but can log into the console.
If you’re recommending NOPASSWD to sudo, then it can only be because you’re deviating from what I’d consider is best practice in security anyway: you’re introducing your own security-related concerns by giving users that should exist as non-privileged, non-elevatable users (because it runs java) the ability to sudo.
If you’re worried about brute forcing, you can implement Fail2Ban and also reference login failures from /var/log/mineos.auth.log.
There’s so many functionalities available in supplemental utilities like Fail2Ban or iptables, or using normal privilege separation. Not to mention there’s docker and jail systems.
If I’ve missed what you’re describing, please let me know.