Project

General

Profile

Bug #614

Users in groups with ssh access are not actually given shell/ssh access

Added by Jim Pingle almost 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
User manager
Target version:
Start date:
05/21/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

When you add a new user and make it a member of the any group that has ssh privileges, it does not get shell access. It gets added to /etc/passwd but its shell is set to /sbin/nologin

If you add a user and then grant it shell access specifically, it gets a proper shell.

Associated revisions

Revision af31b277 (diff)
Added by Jim Pingle almost 9 years ago

Give users who have "all" privileges shell access. Part of ticket #614

History

#1 Updated by Chris Buechler almost 9 years ago

Related to this, we also need to look at how shell access in general should be handled for non-root users. The console menu doesn't work correctly for such users. But then when they can escape out to a shell, they likely might as well have sudo access. Someone with decent skill could easily find many ways to escalate privileges at this point, given the codebase wasn't originally designed for doing this.

Certain screens/capabilities need a warning - exec.php, backup/restore, (to a slightly lesser extent) CLI access all come with the ability for the user to escalate privileges to any other portion of the system.

#2 Updated by Jim Pingle almost 9 years ago

Yeah that could get hairy, especially since any shell user can read the raw config which (necessarily) contains some info that they may not otherwise have access to see. Perhaps we need some kind of restricted shell or chroot environment where these users get dumped, but it seems easier to just assume that anyone getting ssh access is effectively root.

I'm not sure how people would intend to use this unless it was for admin privileges. The SCP privilege will let them restrict to file copying (if you install scponly) but the only other real use might be for letting people make SSH tunnels, which they can probably do with some other restricted shell.

#3 Updated by Erik Fonnesbeck almost 9 years ago

For tunnels, it could probably even be a shell that just says something like "Press any key when you want to log out of this SSH session." and doesn't do anything else. It would be very easy to make a C program or shell script that does this.

#4 Updated by Jim Pingle almost 9 years ago

I've changed the shell code around a bit so that normal users with shell access just get tcsh as a shell, because the menu doesn't work properly for non-admin users.

I suppose we could either include sudo and setup the menu to use sudo if the user isn't id 0, or have a low-privilege menu with items that do work.

#5 Updated by Jim Pingle almost 9 years ago

  • Status changed from New to Feedback

The assigning of ssh privileges should be OK now. If a user is a member of a group that contains the user-shell-access privilege, or has "all" privileges, as the admins group does, they will get shell access.

Because the menu would have issues with non-root users, I just made it give them tcsh for a shell.

Now we just need a little more logic and an added privilege for "ssh tunnel access" to use the pre-existing ssh-tunnel-shell program and this should be all squared away.

#6 Updated by Jim Pingle almost 9 years ago

Meant to also say in that update that the ssh tunnel shell should really be in a separate ticket since it isn't directly related to the issue of privileges not being assigned.

#7 Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF