User-delegated-Panel, think tank

stephdl · May 11, 2015, 7:12pm

I’m looking a bit in that direction a module to delegate to users permission to do administrative tasks.

For now I have templatised the /usr/share/nethesis/NethServerAuthorization/base.json but of course my guess is … do there are best ideas @davidep @giacomo

why ?

If you change the code in the core…i can miss an evolution in term of security.

do you have planned something in that direction ?

below the code of my quick template (i did the same for user). template-begin and template-end get respectively ‘[’ and ‘]’ and all the default settings are in 10Base. For correct ownership I use a templates.metadata

{ 
use strict;
use warnings;

use esmith::AccountsDB;
use esmith::DB;

my $a = esmith::AccountsDB->open;
my @groups = $a->groups();

foreach my $groups (@groups) {
    my $name = $groups->key;
    my $prop = $a->get_prop("$name",'AdminPanels') || '';
    next if ($prop eq '');
    my @panel = split(",", ($prop || "") );

$OUT .=<<'HERE'
,
    {
        "Id": 13891041299,
        "Final": true,
        "Effect": "ALLOW",
HERE
;

    $OUT.= qq (        "Subject": ".groups HAS $name",\n);
    $OUT.= qq (        "Action": "*",\n);
    $OUT.= qq (        "Resource": ["SomeoneElse OR Oneself","Nethgui\\\\System\\\\EsmithDatabase:*",);

    my $count = 1;

    foreach my $panel (@panel) {
        my $countarray = scalar @panel;

        $OUT.= qq("NethServer\\\\Module\\\\);
        $OUT.= qq ($panel:*",) if ($count < $countarray);
        $OUT.= qq ($panel:*") if ($count == $countarray);
        $count++;
    }

    $OUT .= qq (],\n);
    $OUT.= qq (        "Description":\n);
    $OUT.= qq (        "The group $name has no restrictions to $prop"\n);
    $OUT.='    }';

}
}

giacomo · May 12, 2015, 7:09am

I really like the idea to have a simple page where the admin can associate the users to a list of pre-defined roles.
I know there are some built-in roles based on group names, but it’s all inside @davidep head and there is no documentation about it: I don’t even know a where this thing is coded!

So, I’d like to start from:

what are the built-in roles?
how we can use them?
what are the authorization of these roles?

Then:

do we need to create new roles?
can the user edit the authorizations of an existing role?

Please Davide, help us!

davidep · May 12, 2015, 8:10am

By now, the concept of “role” is the same of “group membership”.

If an user is member of a particular group, it inherits the group access permissions.

Access rules (to the Server Manager) are defined by json files under

/usr/share/nethesis/NethServer/Authorization/

base.json states that

members of administrators (or adm) are root-equivalents
members of managers have access to any module in the “Management” category

base.json comes with nethserver-base package, so every system has it by default.

To use these builtin roles

create the groups
put users into them

Nethgui does not look inside /etc, so existing roles cannot be changed locally. Policies come only from RPMs.

But we can develop further the Authorizartion feature. I’d like to

see if Symfony Security component can provide the basic implementation
read policy files (whatever format) also from /etc/, allowing local customization (by hand, template…) of RPM based rules.

I’m not sure an editor panel would be necessary if good default roles/groups are provided and a simple customization path is provided for special needs. We already have /etc/e-smith/template-custom for that.

stephdl · May 12, 2015, 5:23pm

Thank you for your interest and answers.

The problem with static roles defined by architects of NethServer is that this will never fit the need of contributors. I mean you will decide and create categories of users or groups, but what about of exceptions…panels created after your reflexion, or forks of other panels

For example, now I can create really thin permissions, a user can be allowed to use some, all, or just one Panel. Sometime you don’t need to delegate all Panels…or same for a group.

The delegation should be considered also for one User.

What I have in head should be that to templatise /usr/share/nethesis/NethServer/Authorization/base.json with the event nethserver-base-update (could be others also) and contributors could add their own permissions like I did for users and groups.

At the end you could change permissions with db or a panel (I know that you love Panel @giacomo)

for group

db accounts setprop adminenmousse AdminPanels Ssh,LogViewer,Group,SharedFolder

or for all panels

db accounts setprop adminenmousse AdminPanels *

for user

db accounts setprop plop AdminPanels Ssh,LogViewer,Group,SharedFolder

or for all panels

db accounts setprop plop AdminPanels *

Obviously I have a Panel in Head, I need to search a bit how to do it but in short I want to make an array of all *.php in /usr/share/nethesis/NethServer/Modules and build a SELECTOR_MULTIPLE with checkbox

What I want is to automatise the panel creation for Modules created after this one…perhaps we could templatise the translation file and retrieve Panel name from /usr/share/nethesis/NethServer/Languages

Of course works in nethserver-base could be done by me, under your orders… sirs

Do I’m dreaming ?

davidep · May 13, 2015, 9:29am

I’m a bit confused and I need a concrete example here My experience is: the lack of initial requirements leaded me to an over-engineered implementation. I don’t want repeat the same mistake.

BTW, Let’s see what we have now: the current (undocumented and over-engineered) authorization model is inspired by

When a module implements the PolicyEnforcementPointInterface, it receives a PDP that authorizes access to specific resources (DB, module…).

A module can implement the desired level of resource granularity, and any package can deploy its set of json rules. Rules are sorted by their weight and can be overridden.

Very cool, very complex and over-engineered

I agree: the template can simplify the policies management. As I said before, the json-based implementation is too complex and I’d prefer to find another one (Symfony component?).

The Menu module performs a similar task: have a glance to its code to see how it receives a ModuleSetInterface object.

To sum up I think we need:

clear requirements from contribs and core modules
find a simple (existing) implementation
write down a template for the policy configuration

stephdl · May 14, 2015, 8:21am

Honestly it took me one hour sunday night to write and play with my first template, so I don’t think it is really so much hard to understand and so over-engineered as you are worrying. I have no problem to continue with it.

As a matter of authorization I provide a ‘*’ for all actions, but restricted on specific module.

When I’m speaking of contributor needs I mean to let the implementation opened, like you did for example with the Ibay template and Module. The structure allows the contributor to add its templates ‘easily’ and its panel in the same way.

If I want to compare to SME Server, It will need some discussions to add the template in the core, and a mandatory new panel elsewhere in the server-manager-> this is why the contrib shared-folder was created, a discussion shortcut

So I don’t ask you to reinvent the wheel

As you want but we have a proverb in France ‘un tien vaut mieux que deux tu l’auras’ (please @filippo_carletti can you translate, I know that you love France and Paris)

Concerning contributor needs about authorization there are not different from the core, and I do love simple things :
if the user or the group are allowed then full control on the Panel and all its plugins

For now I’m just interested by a template of base.json, I don’t want to start with a custom-template.

I will look about your module given as example.

Xonline · May 11, 2017, 4:51pm

However this topic is old, it is still an issiue for me because i would like to
create levels in the administration of the servers we build.

root > Server Owner
admin > Server administrator
administrator > Server administrator (Windows Active Directory)
users > Userlevel

Please follow this procedure to make ik (almost) work:
Create a new group called “managers”
edit the “admin@yourserver.xx” user and remove the group “domain admin” from this user
Now instead of above, add the group “managers” to this user.

edit the “administraor@yourserver.xx” user and remove the group “domain admin” from this user
Now instead of above, add the group “managers” to this user.
( I have not tested if there were issiues with Windows AD / DC and user rights on this change )

Make sure the password of your “root” user is different than that from the admin / administrator

Also create “manager” user, grant this user to te new “managers” group only, and give it a password.
Also create “another” user, grant this user to te new “managers” group only, and give it a password.

NoW you’ll end up with the following

GOOD: A “root” user who can manage everything.
WRONG: An “admin” user who can manage everything!
WRONG: An “administrator” user who can change the password of the “admin” user!
WRONG: A “manager” user who can change the password of the “admin” user!
GOOD: An “Another” user who can only change its own password

In this situation members of the group “managers” can get acces to the admin account by changing
its password and then login as admin to mess up everything or worse!

To solve this problem you must change the following file:

//usr/share/nethesis/NethServer/Authorization/base.json

See Row 6 : “Subject”: [“root”, “admin”, “.groups HAS adm”],
Change to : “Subject”: [“root”, “.groups HAS adm”],

Now you will have:
GOOD: A “root” user who can manage everything.
GOOD: An “admin” user who has manager previleges (Users, Folders, Groups, Virtuals hosts, …)
GOOD: An “administrator” user who can change the password of the “admin” user!
GOOD: A “manager” user who can change the password of the “admin” user!
GOOD: An “Another” user who can only change its own password

In this scenario the user “manager” is the same as “admin” and thus not needed, the person who is
going to take care of the user management is going to be “admin” ( and for windows “administrator”.

The big difference:

Only the “root” user has access to the full server-manager to install software, change network
settings, add users to openVPN and so on…

Quick commandline fix: ( Copy and Paste )

mv //usr/share/nethesis/NethServer/Authorization/base.json //usr/share/nethesis/NethServer/Authorization/base.json.old
awk ‘{ if (NR == 6) print “"Subject": ["root", ".groups HAS adm"],”; else print $0}’ //usr/share/nethesis/NethServer/Authorization/base.json.old > //usr/share/nethesis/NethServer/Authorization/base.json

Fix 403 - Forbidden 1327681977+1327499272 @ “managers” dashboard.

The dashboard for “managers” has an error now, to fix this the same way as it was for users
you must change the following:

//usr/share/nethesis/NethServer/Module/Dashboard.php

See Row 40 : $isAdmin = ($user->hasCredential(‘username’) && in_array($user->getCredential(‘username’), array(‘admin’,‘root’)))
Change to : $isAdmin = ($user->hasCredential(‘username’) && in_array($user->getCredential(‘username’), array(‘root’)))

mv //usr/share/nethesis/NethServer/Module/Dashboard.php //usr/share/nethesis/NethServer/Module/Dashboard.php.old
awk ‘{ if (NR == 40) print "$isAdmin = ($user->hasCredential(’'‘username’'‘) && in_array($user->getCredential(’'‘username’'‘), array(’'‘root’'‘)))"; else print $0}’ //usr/share/nethesis/NethServer/Module/Dashboard.php.old > //usr/share/nethesis/NethServer/Module/Dashboard.php