root user privileges on per user, per environment basis ?

[Aaron Peeler <aa...@ncsu.edu>]

The latest commit by Brian highlighted that a feature change for root/admin 
access might be needed for a future release(maybe for release 2.2).

Background:

Under certain provisioning engines or OS modules 'root/admin' level access 
is granted because the node can be reloaded. Also enabling root/admin 
access provides a lot of user benefits. Under non-imaging reservations it 
gives users a level of control they can't get in traditional lab machines 
or remote access machines, it provides a sense of ownership, etc. The 
modules that do provide root/admin access are xcat.pm,vmware.pm and esx.pm 
perl modules.

There is another provisioning engine called Lab.pm - it is for *nix 
machines that are locked down. Basically it opens and closes access for the 
requesting account. There is no reloading of the node involved and no root 
privileges. It is for standalone machines somewhere on the network, where 
the sysadmin does not want(or cannot allow) the users to have root level 
access.


Within the modules xcat.pm,vmware.pm,esx.pm the Linux based installs and 
environments uses the default Linux.pm OS module which uses the group 
'ncsu' when the user account gets created on the node. This group is used 
as a method to quickly provide full sudo access for the requesting user. 
The user group ncsu is defined in /etc/sudoers when the image is 
setup(undocumented).

Suggested changes/enhancement:

Obviously the group name ncsu should be changed to something more 
intuitive, 'rootusers' or 'powerusers' or whatever. The default 
grant_access routine in Linux.pm would create the group and populate the 
sudoers file - if the group didn't already exist.

So the question is.
Are there any thoughts on doing this on a either or all of the following:
- per image/environment basis
- a per user basis
- a user group attribute
- or at a privilege node

Based on the provisioning or OS module the default could be to provide 
root/admin access. Then start to examine the attributes for the user, the 
user group, then the image. We'd have to defined which one 
'user|usergroup|image|privnode' overrules the others.
For example the image profile would have to allow root access first, then 
if the user is granted root access either at a privilege node or .

If triggered the grant_access routine would be responsible for providing(or 
not providing) root or admin level access.

A problem I can see immediately with this if we did all the options, is how 
to distinguish which one is final say. If the imageprofile is ok to allow 
root access - but if the user is granted image checkout at two or more 
nodes for the same image, one privilege node allowing root and the other 
privilege node not allowing root, which gets chosen?

So it might make sense to grant root only on per image basis? Kind of like 
what we're doing now, just the modification would be for the grant_access 
routines to create the needed rootuser group.

I've not given this a great deal of thought and I'm probably missing 
something, or it's just all unclear to folks.  At this point this is just 
brain storming on how to make the root/administrative permission more 
dynamic.

BTW - created jira issue VCL-125 on this.

Aaron

Re: root user privileges on per user, per environment basis ?

[Andy Kurth <an...@ncsu.edu>]

I'm beginning to work on adding new functionality which will allow root access 
to be enabled or disabled per image (VCL-125).  Please reply if you have any 
thoughts or suggestions.

Here's what I'm thinking:
Add a column to the imagemeta table called 'rootaccess'. The default will be 1.

In order to expose the new column, utils.pm:get_imagemeta_info() and 
DataStructure.pm need to be updated. This will allow the value to be retrieved 
via $self->data->get_imagemeta_root_access().

I will begin by making the new function available for OS's using the modularized 
Windows_mod.pm class.  Windows_mod.pm::create_user() is where users get added to 
the Administrators group.  It will be updated to check the rootaccess value.  If 
not equal to 1, users won't be added to the Administrators group.

The frontend Edit Image page will need to be updated to allow image admins the 
ability to configure the new option.

-Andy


Aaron Peeler wrote:
> 
> Actually the mantra of VCL is broader than that - it's to broker remote 
> access to a resource. This resource being a node in a datacenter(that 
> can be reloaded), a standlone lab machine, or even a 'service'.
> 
> There are a few reasons why this should be optional.
> 
> One is CIPA related. With more users possibly using this in K-12 space 
> and since there is not a clear definition of how to make something CIPA 
> compliant. Folks might need to have this setting as an option to match 
> their CIPA solution.
> 
> The other is that not all the environments that VCL brokers access for - 
> needs to be or should be reloaded. One example - is the traditional lab 
> machines, these are idle resources that set in labs at night. Even 
> though some Univ are exploring the ideas of trimming back traditional 
> labs, it's a valuable resource that gets un-used in off hours when the 
> computing labs are closed. We don't want to reload this type of resource 
> - but only broker the access to it.
> 
> So it seems like the per-image basis is good enough to start with.
> 
> Aaron
> 
> --On March 30, 2009 5:26:26 PM -0400 Brian Bouterse <bm...@ncsu.edu> 
> wrote:
> 
>> Since we're brainstorming, why not give all users sudo access all the
>> time and not have a distinction between root and/or admin level access?
>> The mantra of VCL (I think) is to provision a resource and then blow it
>> away, so why not let them have freedom in this temporary environment all
>> the time?
>>
>> If there is a distinction between root/admin, doing it on a per-image
>> basis alone, makes sense to me.
>>
>> Best,
>> Brian
>>
>>
>> Brian Bouterse
>> Secure Open Systems Initiative
>> 919.698.8796
>>
>>
>>
>>
>> On Mar 30, 2009, at 4:25 PM, Aaron Peeler wrote:
>>
>>>
>>> The latest commit by Brian highlighted that a feature change for
>>> root/admin access might be needed for a future release(maybe for
>>> release 2.2).
>>>
>>> Background:
>>>
>>> Under certain provisioning engines or OS modules 'root/admin' level
>>> access is granted because the node can be reloaded. Also enabling
>>> root/admin access provides a lot of user benefits. Under non-imaging
>>> reservations it gives users a level of control they can't get in
>>> traditional lab machines or remote access machines, it provides a
>>> sense of ownership, etc. The modules that do provide root/admin
>>> access are xcat.pm,vmware.pm and esx.pm perl modules.
>>>
>>> There is another provisioning engine called Lab.pm - it is for *nix
>>> machines that are locked down. Basically it opens and closes access
>>> for the requesting account. There is no reloading of the node
>>> involved and no root privileges. It is for standalone machines
>>> somewhere on the network, where the sysadmin does not want(or cannot
>>> allow) the users to have root level access.
>>>
>>>
>>> Within the modules xcat.pm,vmware.pm,esx.pm the Linux based installs
>>> and environments uses the default Linux.pm OS module which uses the
>>> group 'ncsu' when the user account gets created on the node. This
>>> group is used as a method to quickly provide full sudo access for
>>> the requesting user. The user group ncsu is defined in /etc/sudoers
>>> when the image is setup(undocumented).
>>>
>>> Suggested changes/enhancement:
>>>
>>> Obviously the group name ncsu should be changed to something more
>>> intuitive, 'rootusers' or 'powerusers' or whatever. The default
>>> grant_access routine in Linux.pm would create the group and populate
>>> the sudoers file - if the group didn't already exist.
>>>
>>> So the question is.
>>> Are there any thoughts on doing this on a either or all of the
>>> following:
>>> - per image/environment basis
>>> - a per user basis
>>> - a user group attribute
>>> - or at a privilege node
>>>
>>> Based on the provisioning or OS module the default could be to
>>> provide root/admin access. Then start to examine the attributes for
>>> the user, the user group, then the image. We'd have to defined which
>>> one 'user|usergroup|image|privnode' overrules the others.
>>> For example the image profile would have to allow root access first,
>>> then if the user is granted root access either at a privilege node
>>> or .
>>>
>>> If triggered the grant_access routine would be responsible for
>>> providing(or not providing) root or admin level access.
>>>
>>> A problem I can see immediately with this if we did all the options,
>>> is how to distinguish which one is final say. If the imageprofile is
>>> ok to allow root access - but if the user is granted image checkout
>>> at two or more nodes for the same image, one privilege node allowing
>>> root and the other privilege node not allowing root, which gets
>>> chosen?
>>>
>>> So it might make sense to grant root only on per image basis? Kind
>>> of like what we're doing now, just the modification would be for the
>>> grant_access routines to create the needed rootuser group.
>>>
>>> I've not given this a great deal of thought and I'm probably missing
>>> something, or it's just all unclear to folks.  At this point this is
>>> just brain storming on how to make the root/administrative
>>> permission more dynamic.
>>>
>>> BTW - created jira issue VCL-125 on this.
>>>
>>> Aaron
>>>
>>
> 
> 
> 
> Aaron Peeler
> OIT Advanced Computing
> College of Engineering-NCSU
> 919.513.4571
> http://vcl.ncsu.edu

-- 
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_kurth@ncsu.edu
919.513.4090

Re: root user privileges on per user, per environment basis ?

[Aaron Peeler <aa...@ncsu.edu>]

Actually the mantra of VCL is broader than that - it's to broker remote 
access to a resource. This resource being a node in a datacenter(that can 
be reloaded), a standlone lab machine, or even a 'service'.

There are a few reasons why this should be optional.

One is CIPA related. With more users possibly using this in K-12 space and 
since there is not a clear definition of how to make something CIPA 
compliant. Folks might need to have this setting as an option to match 
their CIPA solution.

The other is that not all the environments that VCL brokers access for - 
needs to be or should be reloaded. One example - is the traditional lab 
machines, these are idle resources that set in labs at night. Even though 
some Univ are exploring the ideas of trimming back traditional labs, it's a 
valuable resource that gets un-used in off hours when the computing labs 
are closed. We don't want to reload this type of resource - but only broker 
the access to it.

So it seems like the per-image basis is good enough to start with.

Aaron

--On March 30, 2009 5:26:26 PM -0400 Brian Bouterse <bm...@ncsu.edu> 
wrote:

> Since we're brainstorming, why not give all users sudo access all the
> time and not have a distinction between root and/or admin level access?
> The mantra of VCL (I think) is to provision a resource and then blow it
> away, so why not let them have freedom in this temporary environment all
> the time?
>
> If there is a distinction between root/admin, doing it on a per-image
> basis alone, makes sense to me.
>
> Best,
> Brian
>
>
> Brian Bouterse
> Secure Open Systems Initiative
> 919.698.8796
>
>
>
>
> On Mar 30, 2009, at 4:25 PM, Aaron Peeler wrote:
>
>>
>> The latest commit by Brian highlighted that a feature change for
>> root/admin access might be needed for a future release(maybe for
>> release 2.2).
>>
>> Background:
>>
>> Under certain provisioning engines or OS modules 'root/admin' level
>> access is granted because the node can be reloaded. Also enabling
>> root/admin access provides a lot of user benefits. Under non-imaging
>> reservations it gives users a level of control they can't get in
>> traditional lab machines or remote access machines, it provides a
>> sense of ownership, etc. The modules that do provide root/admin
>> access are xcat.pm,vmware.pm and esx.pm perl modules.
>>
>> There is another provisioning engine called Lab.pm - it is for *nix
>> machines that are locked down. Basically it opens and closes access
>> for the requesting account. There is no reloading of the node
>> involved and no root privileges. It is for standalone machines
>> somewhere on the network, where the sysadmin does not want(or cannot
>> allow) the users to have root level access.
>>
>>
>> Within the modules xcat.pm,vmware.pm,esx.pm the Linux based installs
>> and environments uses the default Linux.pm OS module which uses the
>> group 'ncsu' when the user account gets created on the node. This
>> group is used as a method to quickly provide full sudo access for
>> the requesting user. The user group ncsu is defined in /etc/sudoers
>> when the image is setup(undocumented).
>>
>> Suggested changes/enhancement:
>>
>> Obviously the group name ncsu should be changed to something more
>> intuitive, 'rootusers' or 'powerusers' or whatever. The default
>> grant_access routine in Linux.pm would create the group and populate
>> the sudoers file - if the group didn't already exist.
>>
>> So the question is.
>> Are there any thoughts on doing this on a either or all of the
>> following:
>> - per image/environment basis
>> - a per user basis
>> - a user group attribute
>> - or at a privilege node
>>
>> Based on the provisioning or OS module the default could be to
>> provide root/admin access. Then start to examine the attributes for
>> the user, the user group, then the image. We'd have to defined which
>> one 'user|usergroup|image|privnode' overrules the others.
>> For example the image profile would have to allow root access first,
>> then if the user is granted root access either at a privilege node
>> or .
>>
>> If triggered the grant_access routine would be responsible for
>> providing(or not providing) root or admin level access.
>>
>> A problem I can see immediately with this if we did all the options,
>> is how to distinguish which one is final say. If the imageprofile is
>> ok to allow root access - but if the user is granted image checkout
>> at two or more nodes for the same image, one privilege node allowing
>> root and the other privilege node not allowing root, which gets
>> chosen?
>>
>> So it might make sense to grant root only on per image basis? Kind
>> of like what we're doing now, just the modification would be for the
>> grant_access routines to create the needed rootuser group.
>>
>> I've not given this a great deal of thought and I'm probably missing
>> something, or it's just all unclear to folks.  At this point this is
>> just brain storming on how to make the root/administrative
>> permission more dynamic.
>>
>> BTW - created jira issue VCL-125 on this.
>>
>> Aaron
>>
>



Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu

Re: root user privileges on per user, per environment basis ?

[Brian Bouterse <bm...@ncsu.edu>]

Since we're brainstorming, why not give all users sudo access all the  
time and not have a distinction between root and/or admin level  
access?  The mantra of VCL (I think) is to provision a resource and  
then blow it away, so why not let them have freedom in this temporary  
environment all the time?

If there is a distinction between root/admin, doing it on a per-image  
basis alone, makes sense to me.

Best,
Brian


Brian Bouterse
Secure Open Systems Initiative
919.698.8796




On Mar 30, 2009, at 4:25 PM, Aaron Peeler wrote:

>
> The latest commit by Brian highlighted that a feature change for  
> root/admin access might be needed for a future release(maybe for  
> release 2.2).
>
> Background:
>
> Under certain provisioning engines or OS modules 'root/admin' level  
> access is granted because the node can be reloaded. Also enabling  
> root/admin access provides a lot of user benefits. Under non-imaging  
> reservations it gives users a level of control they can't get in  
> traditional lab machines or remote access machines, it provides a  
> sense of ownership, etc. The modules that do provide root/admin  
> access are xcat.pm,vmware.pm and esx.pm perl modules.
>
> There is another provisioning engine called Lab.pm - it is for *nix  
> machines that are locked down. Basically it opens and closes access  
> for the requesting account. There is no reloading of the node  
> involved and no root privileges. It is for standalone machines  
> somewhere on the network, where the sysadmin does not want(or cannot  
> allow) the users to have root level access.
>
>
> Within the modules xcat.pm,vmware.pm,esx.pm the Linux based installs  
> and environments uses the default Linux.pm OS module which uses the  
> group 'ncsu' when the user account gets created on the node. This  
> group is used as a method to quickly provide full sudo access for  
> the requesting user. The user group ncsu is defined in /etc/sudoers  
> when the image is setup(undocumented).
>
> Suggested changes/enhancement:
>
> Obviously the group name ncsu should be changed to something more  
> intuitive, 'rootusers' or 'powerusers' or whatever. The default  
> grant_access routine in Linux.pm would create the group and populate  
> the sudoers file - if the group didn't already exist.
>
> So the question is.
> Are there any thoughts on doing this on a either or all of the  
> following:
> - per image/environment basis
> - a per user basis
> - a user group attribute
> - or at a privilege node
>
> Based on the provisioning or OS module the default could be to  
> provide root/admin access. Then start to examine the attributes for  
> the user, the user group, then the image. We'd have to defined which  
> one 'user|usergroup|image|privnode' overrules the others.
> For example the image profile would have to allow root access first,  
> then if the user is granted root access either at a privilege node  
> or .
>
> If triggered the grant_access routine would be responsible for  
> providing(or not providing) root or admin level access.
>
> A problem I can see immediately with this if we did all the options,  
> is how to distinguish which one is final say. If the imageprofile is  
> ok to allow root access - but if the user is granted image checkout  
> at two or more nodes for the same image, one privilege node allowing  
> root and the other privilege node not allowing root, which gets  
> chosen?
>
> So it might make sense to grant root only on per image basis? Kind  
> of like what we're doing now, just the modification would be for the  
> grant_access routines to create the needed rootuser group.
>
> I've not given this a great deal of thought and I'm probably missing  
> something, or it's just all unclear to folks.  At this point this is  
> just brain storming on how to make the root/administrative  
> permission more dynamic.
>
> BTW - created jira issue VCL-125 on this.
>
> Aaron
>