Isilon RBAC model and disabling root SSH access

[Jim Bruce]

Has anyone tried to manage their Isilon cluster with root SSH access disabled? I know with OneFS 7.2 Simulator, the new RBAC allows a lot of the main management commends to run with sudo, however I cannot figure out how to allow an admin user to su to root to do more low level basic stuff (like chmod and chflags) which seem to be disabled.  I tried looking into adding the admin user into the sudoers file with 'isi visudo' but the formatting for the entries seems very different to the usual sudoers file and I don't want to bork the entire cluster if I make a mistake with adding sudoer entries incorrectly.

[John Beranek - PA]

We've configured our Isilons so that admins log on as their AD users and use 'sudoo' to perform the commands that are not yet RBAC enabled.

The 'sudoers' entries we've added using "isi visudo" are standard, and we just allowed a specific AD group to have root sudo access.

Not sure you mean about the sudoers file though, as with OneFS 7.1 and 7.0 the file you get with isi_visudo starts as follows, and contains no rules (well, there is a single option on our 7.1 cluster):

## Sudoers override file.
##
## This file overrides the default configuration for sudo as provided by
## Isilon. The defaults can be found at /etc/mcp/templates/sudoers. Do not
## edit /etc/mcp/templates/sudoers.
##

We've not gone as far as disabling root SSH, as the few times we connect as root is when EMC Support are accessing the cluster, as this is what they expect...

John

[DAQ]

John,

How many Access Zones are your running with?  I am trying to work on securing and isolating the management of the Isilon cluster from the user visible Access Zones.  

Also, are you doing anything as an admin user that you have found you cannot use 'sudo' for (example; I cannot use 'sudo chmod' as the admin user, which I know is kind of not standard for managing file permissions on Isilon, but for working with config files that are not part of the 'isi' command scheme, it is necessary, i.e. for configuring Aspera for Isilon config files and making changes to perl scripts running as part of the pre-post actions for Aspera for Isilon).

I keep running into the error "Sorry, user admin is not allowed to execute '<command>'" when I am logged in as the admin user.  

I am assuming that the 'sudoers' entry you have added is:

ADMINS ALL=(ALL) ALL

Or some variation delimiting a restricted set of commands that you want your admins to be able to use.  Is this all that is needed?

[John Beranek - PA]

We only have the single access zone. No issues with running "sudo chmod" on either OneFS 7.0.2.4 or 7.1.1.2. sudoers rule just looks like:

"%Example Isilon Admin Group"        ALL=(ALL)       ALL

John

[Andrew Stack]

Along this same theme...we have a need for an rbac solution whereby a user can perform a move (mv) of some data from point A to point B.  I don't see a sudo command for this...anybody know of a means?

Many Thanks,

Andrew Stack

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrew Stack

Sr. Storage Administrator

Genentech

Cell - 650.867.5524

[John Beranek - PA]

You could write a small shell script and then provide sudo access to that. Beware that if you do allow user parameters to be entered that people can be sneaky with "../". e.g. with a shell script "move_file.sh":

================================

#!/bin/sh

mv /ifs/basedir1/$1 /ifs/basedir2/$2

================================

A user could call:

move_file.sh ../../basedir3 ../../basedir4

and thereby escape the expected area of influence. You'd need to spot the .. in the shell script and disallow the operation...

Storing shell scripts in /ifs also has the annoying problem that you can't make files under /ifs executable, so you need to run:

sh /ifs/bin/move_file.sh

instead of

/ifs/bin/move_file.sh

John

[Dan Pritts]

John Beranek - PA wrote:
> You could write a small shell script and then provide sudo access to
> that. Beware that if you do allow user parameters to be entered that
> people can be sneaky with "../". e.g. with a shell script "move_file.sh":
>
> ================================
> #!/bin/sh
>
> mv /ifs/basedir1/$1 /ifs/basedir2/$2
> ================================
>
> A user could call:
>
> move_file.sh ../../basedir3 ../../basedir4
>
> and thereby escape the expected area of influence. You'd need to spot
> the .. in the shell script and disallow the operation...

...as well as about a million other possible problems.

If your goal is to prevent good people from making mistakes, it's more
or less achievable. I wrote a similar script at a former employer,
unfortunatelyi don't have it.

If your goal is to prevent an malicious attacker from doing something
they shouldn't, well, good luck. You're gonna need it.

danno
--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan