FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 04-01-2008, 08:42 AM
Sankarshan Mukhopadhyay
 
Default Cobbler and the ownership module, question about policies?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael DeHaan wrote:

| Possible Answer2 -- If you're not in the admin group, you can't edit
| kickstart template files at all.

Would users not in Admin Group require editing rights ? Or, should they
be allowed to edit ?

| Possible Answer3 -- Remove kickstart editing from the WebUI, and
| encourage users to create kickstart templates where they have filesystem
| access (i..e their home directories)

Possibly the best option if the answer is Yes to above.

| Answer? I think the answer is Subprofile B is promoted to a full
| profile with all of the inherited fields set to the values of Profile A.
| However this is complicated and confusing so "No deletion allowed" may
| be the better route.

No deletion allowed seems saner.


| Any thoughts on the above from those who have a vested interest in
| controlling access to cobbler objects through the WebUI?

i don't have a vested interest yet but would sure be watching the
responses to these interesting questions




- --

http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH8fVdXQZpNTcrCzMRAqJQAKCien3eJsMFO14ZehgmoD j4oJeyjQCeLHn1
OwUSw1UEw1fPkfA0xJXtI44=
=oESY
-----END PGP SIGNATURE-----

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 12:39 PM
Bryan Kearney
 
Default Cobbler and the ownership module, question about policies?

Michael DeHaan wrote:

So,

Warning -- technical email

I have a pretty good ownership module going for Cobbler now
(https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), that
allows you to say that objects are owned by certain users and/or groups,
and prevents users not in those groups (except for an admin group) to be
able to edit those objects. This is designed for very large
organizations that may want lab admins to control certain profiles, but
not all of them (for instance, a build lab versus a test lab versus a
production datacenter, etc).
In this implementation, users in the admin group have access to all
objects always, and by default all objects are created with no editing
restrictions unless the creator decides to lock them down. The
command line has none of these restrictions so you can always
recover/reconfigure things with root if you find you've somehow locked
yourself out. (It's also coded up so you can't use the WebUI to remove
your own access from an object).


There are a couple of policy questions for this dealing with some of the
corner cases.


(A) What to do about kickstart editing in the WebUI. This is the "fun"
corner case to figure out.


The WebUI contains a very basic kickstart template editor (it's just a
text field for now).
Possible Answer1? I think the solution is that a kickstart template file
can be edited if the user editing it is allowed to edit ALL
profiles/systems making use of it. This is a bit of a catch 22 as it
would be possible to create a system using a template file, just for the
purpose of making that user not be able to edit it. This shouldn't
happen but is technically possible.
Possible Answer2 -- If you're not in the admin group, you can't edit
kickstart template files at all.


Possible Answer3 -- Remove kickstart editing from the WebUI, and
encourage users to create kickstart templates where they have filesystem
access (i..e their home directories)


For testing, I have liked the ability to edit he ks file and not need to
log into the box. If possible, please keep it. It may be heinous, but is
there a model where each ks has a security item associated to it (e.g. a
role) or ks files can be grouped and a role associated to the group?


----

(B) What do to about "orphanage".

If UserA owns ProfileA, and UserB owns SystemB, which depends on
ProfileB, what happens if UserA wants to delete ProfileA?


Answer? The profile cannot be deleted.

If UserA owns ProfileA, and UserB owns SubprofileB, what happens when
UserA wants to delete ProfileA?


Answer? I think the answer is Subprofile B is promoted to a full
profile with all of the inherited fields set to the values of Profile A.
However this is complicated and confusing so "No deletion allowed" may
be the better route.


First cut, no delete. Every time i have used nested profiles it was
becuase I had nested logic in the kickstart file. So. promoting a
subprofile would cause the subprofile to break.


---

(C) FYI...

Everyone is allowed to run "cobbler sync" if they can authenticate. I
don't think this should be a problem.


Also, if you're in, you can read everything, you just might not be able
to /write/ everything. This also should not be a problem as provisioning
data is basically public if you want to use it in a Fully Automated
Context anyway.


Currently settings, modules.conf, and users.conf can't be edited through
the WebUI as that's a really good way to lock yourself out of the WebUI

altogether

---

Any thoughts on the above from those who have a vested interest in
controlling access to cobbler objects through the WebUI?
Remember this is all off by default and is only there if you want it --
but if you want it, I want to make sure this fits your organizational
needs.


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 04:05 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

Sankarshan Mukhopadhyay wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael DeHaan wrote:

| Possible Answer2 -- If you're not in the admin group, you can't edit
| kickstart template files at all.

Would users not in Admin Group require editing rights ? Or, should they
be allowed to edit ?

Any user in an admin group would have rights to everything, automatically.



| Possible Answer3 -- Remove kickstart editing from the WebUI, and
| encourage users to create kickstart templates where they have
filesystem

| access (i..e their home directories)

Possibly the best option if the answer is Yes to above.

| Answer? I think the answer is Subprofile B is promoted to a full
| profile with all of the inherited fields set to the values of
Profile A.

| However this is complicated and confusing so "No deletion allowed" may
| be the better route.

No deletion allowed seems saner.


Probably.





| Any thoughts on the above from those who have a vested interest in
| controlling access to cobbler objects through the WebUI?

i don't have a vested interest yet but would sure be watching the
responses to these interesting questions


Perfectly valid





- --

http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH8fVdXQZpNTcrCzMRAqJQAKCien3eJsMFO14ZehgmoD j4oJeyjQCeLHn1
OwUSw1UEw1fPkfA0xJXtI44=
=oESY
-----END PGP SIGNATURE-----

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 04:08 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

Bryan Kearney wrote:



Michael DeHaan wrote:

So,

Warning -- technical email

I have a pretty good ownership module going for Cobbler now
(https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization),
that allows you to say that objects are owned by certain users and/or
groups, and prevents users not in those groups (except for an admin
group) to be able to edit those objects. This is designed for very
large organizations that may want lab admins to control certain
profiles, but not all of them (for instance, a build lab versus a
test lab versus a production datacenter, etc).
In this implementation, users in the admin group have access to all
objects always, and by default all objects are created with no
editing restrictions unless the creator decides to lock them
down. The command line has none of these restrictions so you can
always recover/reconfigure things with root if you find you've
somehow locked yourself out. (It's also coded up so you can't use
the WebUI to remove your own access from an object).


There are a couple of policy questions for this dealing with some of
the corner cases.


(A) What to do about kickstart editing in the WebUI. This is the
"fun" corner case to figure out.


The WebUI contains a very basic kickstart template editor (it's just
a text field for now). Possible Answer1? I think the solution is that
a kickstart template file can be edited if the user editing it is
allowed to edit ALL profiles/systems making use of it. This is a bit
of a catch 22 as it would be possible to create a system using a
template file, just for the purpose of making that user not be able
to edit it. This shouldn't happen but is technically possible.
Possible Answer2 -- If you're not in the admin group, you can't edit
kickstart template files at all.


Possible Answer3 -- Remove kickstart editing from the WebUI, and
encourage users to create kickstart templates where they have
filesystem access (i..e their home directories)


For testing, I have liked the ability to edit he ks file and not need
to log into the box. If possible, please keep it. It may be heinous,
but is there a model where each ks has a security item associated to
it (e.g. a role) or ks files can be grouped and a role associated to
the group?


The ownership module is off by default, so if we removed it, it might
only be for that. I think we can find a workable solution though


I'm trying to avoid creating an additional cobbler object wrapping the
kickstarts -- as that ends up creating too many Cobbler objects and
makes things less simpler for newer users (who have this feature turned
off by default, anyway).




----

(B) What do to about "orphanage".

If UserA owns ProfileA, and UserB owns SystemB, which depends on
ProfileB, what happens if UserA wants to delete ProfileA?


Answer? The profile cannot be deleted.

If UserA owns ProfileA, and UserB owns SubprofileB, what happens when
UserA wants to delete ProfileA?


Answer? I think the answer is Subprofile B is promoted to a full
profile with all of the inherited fields set to the values of Profile A.
However this is complicated and confusing so "No deletion allowed"
may be the better route.


First cut, no delete. Every time i have used nested profiles it was
becuase I had nested logic in the kickstart file. So. promoting a
subprofile would cause the subprofile to break.


I agree. Though it might not cause breakage if we promote the
attributes that are marked "inherit", it's clearly non-obvious behavior
to the user.
The admin could always intervene and blow away all objects below it if
required.





---

(C) FYI...

Everyone is allowed to run "cobbler sync" if they can authenticate.
I don't think this should be a problem.


Also, if you're in, you can read everything, you just might not be
able to /write/ everything. This also should not be a problem as
provisioning
data is basically public if you want to use it in a Fully Automated
Context anyway.


Currently settings, modules.conf, and users.conf can't be edited
through the WebUI as that's a really good way to lock yourself out of
the WebUI

altogether

---

Any thoughts on the above from those who have a vested interest in
controlling access to cobbler objects through the WebUI?
Remember this is all off by default and is only there if you want it
-- but if you want it, I want to make sure this fits your
organizational needs.


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 04:24 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

Slinky wrote:



On 31/03/2008, *Michael DeHaan* <mdehaan@redhat.com
<mailto:mdehaan@redhat.com>> wrote:



-slash-

The command line has none of these restrictions so you can always
recover/reconfigure things with root if you find you've somehow locked
yourself out.



Will this always been the case? We'd like to see the same ownership
model apply to the webui and CLI.


Originally I wasn't planning on adding auth to the command line.
Interesting idea.


You could also perhaps get away with making a simple remote command line
that only contained the features you needed and used the existing
XMLRPC/CobblerWeb code as a basis. It would have to accept a username
and password, possibly from doing something like reading ~/.cobbler.rc
or something? If it didn't have to do things like "import" it would be
pretty simple.


There are more complicated alternatives involving ACLs and setuid (non
root), but I think I like that solution better.


Thoughts?




(It's also coded up so you can't use the WebUI to remove
your own access from an object).


^ see above




------------------------------------------------------------------------

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-01-2008, 04:34 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

Michael DeHaan wrote:

Slinky wrote:



On 31/03/2008, *Michael DeHaan* <mdehaan@redhat.com
<mailto:mdehaan@redhat.com>> wrote:



-slash-

The command line has none of these restrictions so you can always
recover/reconfigure things with root if you find you've somehow
locked
yourself out.

Will this always been the case? We'd like to see the same ownership
model apply to the webui and CLI.


Originally I wasn't planning on adding auth to the command line.
Interesting idea.


You could also perhaps get away with making a simple remote command
line that only contained the features you needed and used the existing
XMLRPC/CobblerWeb code as a basis. It would have to accept a
username and password, possibly from doing something like reading
~/.cobbler.rc or something? If it didn't have to do things like
"import" it would be pretty simple.


There are more complicated alternatives involving ACLs and setuid (non
root), but I think I like that solution better.


Thoughts?


Actually the local approach may not be too bad either.

We make cobbler setuid to a cobbler user (not by default, but in this
configuration only), set that user up with ACLs on the right places, and
turn on a flag in settings that says "require_local_auth". We make the
api module in cobbler make the same calls Cobbler is using for remote if
"require_local_auth" is on. And then we require user/password info when
"require_local_auth" is enabled by adding some new arguments or reading
a file in "~/" (or something... yes, kerberos is in the running but we
must also support /non/ kerberos).

Setup will not be super-trivial, but we could perhaps make a sample
script to help people with that configuration.

I see Dan has this use case, but does anyone else? I hesistate to add
to much to support niche cases, though often these seem to be some of
the things larger installs are sometimes looking for.


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-02-2008, 02:54 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

If the setuid option comes in though, we like this a lot. It means we
start to move away from cobbler running as root....


Here's a third simpler design option for a non-root command line that
may not require remoting... I'm a big fan of letting the OS

do the work when possible so this may be a good idea.

-- Set up ACLs for users that need to get access to cobbler data. We
can come up with a script to do this.
-- Do not set cobbler up as setuid/anything, have it run as whatever
user runs it
-- Have the cobbler binary ask the OS for the logged in uid/username,
and use authorization rules based on that (such as ownership).
-- In this case, the OS could use whatever facility it wants for
authentication of user accounts.


We still need to kerberize the web services though for those who aren't
satisfied with the LDAP method, but this allows
you to have ownership and multiple users getting at the cobbler command
line as non-root, and you could choose your OS
authentication mechanism to be anything you want (including
kerb/LDAP/NIS). Make sense? This would
be relatively simple, and since the default authorization policy is
"allow all", it works out of the box without the user

having to configure anything.

The command line can easily check to see if the user has access to the
files in question and would report if ACL's are not set up right.


Should be pretty close to what we want...

--Michael





On 01/04/2008, *Michael DeHaan* <mdehaan@redhat.com
<mailto:mdehaan@redhat.com>> wrote:


Michael DeHaan wrote:

Slinky wrote:



On 31/03/2008, *Michael DeHaan* <mdehaan@redhat.com
<mailto:mdehaan@redhat.com> <mailto:mdehaan@redhat.com
<mailto:mdehaan@redhat.com>>> wrote:


-slash-

The command line has none of these restrictions so you
can always
recover/reconfigure things with root if you find you've
somehow locked
yourself out.
Will this always been the case? We'd like to see the same

ownership model apply to the webui and CLI.


Originally I wasn't planning on adding auth to the command
line. Interesting idea.

You could also perhaps get away with making a simple remote
command line that only contained the features you needed and
used the existing XMLRPC/CobblerWeb code as a basis. It
would have to accept a username and password, possibly from
doing something like reading ~/.cobbler.rc or something? If
it didn't have to do things like "import" it would be pretty
simple.

There are more complicated alternatives involving ACLs and
setuid (non root), but I think I like that solution better.

Thoughts?


Actually the local approach may not be too bad either.

We make cobbler setuid to a cobbler user (not by default, but in
this configuration only), set that user up with ACLs on the right
places, and turn on a flag in settings that says
"require_local_auth". We make the api module in cobbler make the
same calls Cobbler is using for remote if "require_local_auth" is
on. And then we require user/password info when
"require_local_auth" is enabled by adding some new arguments or
reading a file in "~/" (or something... yes, kerberos is in the
running but we must also support /non/ kerberos).
Setup will not be super-trivial, but we could perhaps make a
sample script to help people with that configuration.
I see Dan has this use case, but does anyone else? I hesistate

to add to much to support niche cases, though often these seem to
be some of the things larger installs are sometimes looking for.

--Michael


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com <mailto:et-mgmt-tools@redhat.com>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools




--
Regards
Dan
------------------------------------------------------------------------

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-03-2008, 08:24 PM
Michael DeHaan
 
Default Cobbler and the ownership module, question about policies?

Michael DeHaan wrote:

So,

Warning -- technical email

I have a pretty good ownership module going for Cobbler now
(https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization),
that allows you to say that objects are owned by certain users and/or
groups, and prevents users not in those groups (except for an admin
group) to be able to edit those objects. This is designed for very
large organizations that may want lab admins to control certain
profiles, but not all of them (for instance, a build lab versus a test
lab versus a production datacenter, etc).
In this implementation, users in the admin group have access to all
objects always, and by default all objects are created with no editing
restrictions unless the creator decides to lock them down.


[snip]

So I have what we have currently implemented written up here:


https://fedorahosted.org/cobbler/wiki/AuthorizationWithOwnership

Comments/reviewers welcome. If you would like to test out this code,
or the LDAP code, see the "devel" branch in git.


If you're not familiar with git, there are some relevant commands at the
top of this page:


https://fedorahosted.org/cobbler/wiki/PatchProcess

This policy seems fairly reasonable to me and should allow Cobbler
server admins to offload a fair amount of work to people who own certain
labs/machines/profiles, without also making the UI terribly hard to
use. And, as mentioned before, the old "if you can log in, you're in"
policy is still the default... you do have to turn the ownership system
on. This is still in line for the 1.0 release, as are most likely
improvements to Kerb eros support and the rest of the items here:
https://fedorahosted.org/cobbler/wiki/TheRoadmap


Thanks!

--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 

Thread Tools




All times are GMT. The time now is 06:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org