Citrix XenServer Free: Hypervizor hardening with PAM and RBAC
Good day, colleagues.
XenServer is one of the most popular hypervisors at the moment.
Largely due to the fact that it gives good functionality “for free”.
Therefore, many decisions are made on the Free version without Enterprise features.
And the number of "paid" chips and includes authorization by means of LDAP with the possibility of differentiation of user rights.
Yes, yes, you heard right. In a free XenServer, all users are equal. That is, have the role of Pool Admin.
Let's try to figure out how we can “protect” the hypervisor in the free version?
In accordance with Citrix’s policies, the XenServer versions, called Free and Advanced, are single-user. That is, any user of the system will be perceived by XenAPI as a user with the PoolAdmin role. What negatively affects the process of servicing the hypervisor in terms of information security.
There are at least two ways to solve this problem without purchasing the Enterprise version.
Let's start with the first, more simple and understandable.
')
We will limit the number of users of the system who have access to XenApi.
To do this, first create a file:
In it we will make a list of users allowed to manage the hypervisor.
Thanks to the guys at XenSource for what they did: this is a PAM xapi module for controlling access to the hypervisor. But by default, it is used in the system a little bit wrong.
Therefore, we will delete all entries from it and add new ones:
Now, in order for the user to connect to XenAPI, it is necessary that the record of it be contained in the xapi_allow file. Now you should limit access to this file:
Fine! Now we can “prevent” users of the system that are undesirable to us from managing the hypervisor. Within the limits of the license Free / Advanced, perhaps this is all that can be done.
But you can go further. You can enable the use of RBAC system. To do this, we need to enable external authentication in the system. Here we run into a license restriction, and can not connect to LDAP. But no one bothers us to do this through PAM.
Now we need to assign roles to our users.
But, alas, the Free / Advanced license does not allow this.
Well, let's try to do it without violating the license.
To begin with, shut down all the virtual machines. Subsequent manipulations can damage them.
Now you need to find out the current list of roles on your server.
These are the roles that you can use on your server.
Now add user subjects.
And make sure that everything is done correctly and that your new entity has received pool-admin permissions by default.
Now we need to ask him the necessary rights. Tools for this, unfortunately, are blocked by a license. But no one bothers to do this "manually" by editing the state.db file base.
As a convenient method, I recommend using a “mini” program similar to the one described.
here
Now I will describe how to do it manually. First stop XenAPI.
Now open the file /var/xapi/state.db in your favorite editor:
Now search the file "admin1" (the name of the user you added). We are interested in these lines here:
As you can see, you can also change roles manually in the “roles =” section. We will change the role of our user from “pool-admin” to “read-only”:
Okay! Now run XenAPI back and check the result:
That's all. You can run virtual machines back.
Thus, without violating the license, we were able to use RBAC with PAM authentication.
Hello everyone, thank you for your attention.
XenServer is one of the most popular hypervisors at the moment.
Largely due to the fact that it gives good functionality “for free”.
Therefore, many decisions are made on the Free version without Enterprise features.
And the number of "paid" chips and includes authorization by means of LDAP with the possibility of differentiation of user rights.
Yes, yes, you heard right. In a free XenServer, all users are equal. That is, have the role of Pool Admin.
Let's try to figure out how we can “protect” the hypervisor in the free version?
In accordance with Citrix’s policies, the XenServer versions, called Free and Advanced, are single-user. That is, any user of the system will be perceived by XenAPI as a user with the PoolAdmin role. What negatively affects the process of servicing the hypervisor in terms of information security.
There are at least two ways to solve this problem without purchasing the Enterprise version.
Let's start with the first, more simple and understandable.
')
We will limit the number of users of the system who have access to XenApi.
To do this, first create a file:
[ root @ xenserver / ] # cd / etc /
[ root @ xenserver etc ] # vi xapi_allow
In it we will make a list of users allowed to manage the hypervisor.
root
admin1
admin2
admin3
Thanks to the guys at XenSource for what they did: this is a PAM xapi module for controlling access to the hypervisor. But by default, it is used in the system a little bit wrong.
Therefore, we will delete all entries from it and add new ones:
[ root @ xenserver / ] # cd /etc/pam.d/
[ root @ xenserver pam.d ] # vi xapi
#% PAM-1.0
auth required pam_env.so
auth required pam_listfile.so item = user sense = allow file = / etc / xapi_allow
auth sufficient pam_unix.so try_first_pass nullok
auth required pam_deny.so
account required pam_unix.so
password required pam_cracklib.so try_first_pass retry = 3
password sufficient pam_unix.so try_first_pass use_authtok nullok md5
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [ success = 1 default = ignore ] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Now, in order for the user to connect to XenAPI, it is necessary that the record of it be contained in the xapi_allow file. Now you should limit access to this file:
[ root @ xenserver / ] # chmod 600 / etc / xapi_allow
Fine! Now we can “prevent” users of the system that are undesirable to us from managing the hypervisor. Within the limits of the license Free / Advanced, perhaps this is all that can be done.
But you can go further. You can enable the use of RBAC system. To do this, we need to enable external authentication in the system. Here we run into a license restriction, and can not connect to LDAP. But no one bothers us to do this through PAM.
[ root @ xenserver / ] # xe pool-enable-external-auth auth-type = PAM service-name = pam
Now we need to assign roles to our users.
But, alas, the Free / Advanced license does not allow this.
Well, let's try to do it without violating the license.
To begin with, shut down all the virtual machines. Subsequent manipulations can damage them.
Now you need to find out the current list of roles on your server.
[ root @ xenserver / ] # xe role-list
uuid ( RO ) : 7955168d-7bec-10ed-105f-c6a7e6e63249
name ( RO ) : vm-power-admin
description ( RO ) : snapshot features
uuid ( RO ) : aaa00ab5- 7340 -bfbc-0d1b-7cf342639a6e
name ( RO ) : vm-admin
description ( RO ) : VMs and templates
uuid ( RO ) : fb8d4ff9-310c-a959-0613-54101535d3d5
name ( RO ) : vm-operator
description ( RO ) : VM VMs can interact with VM consoles
uuid ( RO ) : 7233b8e3-eacb-d7da-2c95-f2e581cdbf4e
name ( RO ) : read-only
description ( RO ) :
uuid ( RO ) : b9ce9791-0604-50cd-0649-09b3284c7dfd
name ( RO ) : pool-operator
description ( RO ) : it is a pool and a wide range of resources, including a pool of resources and a workload balancing ( WLB )
uuid ( RO ) : 0165f154-ba3e-034e-6b27-5d271af109ba
name ( RO ) : pool-admin
description ( RO ) :
These are the roles that you can use on your server.
Now add user subjects.
[ root @ xenserver / ] # xe subject-add subject-name = admin1
932d3540-d08c-bbf8-adf8-03c0f9aaaf43
And make sure that everything is done correctly and that your new entity has received pool-admin permissions by default.
[ root @ xenserver / ] # xe subject-list
uuid ( RO ) : 932d3540-d08c-bbf8-adf8-03c0f9aaaf43
subject-identifier ( RO ) : u501
other-config ( MRO ) : subject-name: admin1; subject-uid: u501; subject-gid: g501; subject-gecos :; subject-displayname: admin1; subject-is-group: false ; subject-account-disabled: false ; subject-account-expired: false ; subject-account-locked: false ; subject-password-expired: false
roles ( SRO ) : pool-admin
Now we need to ask him the necessary rights. Tools for this, unfortunately, are blocked by a license. But no one bothers to do this "manually" by editing the state.db file base.
As a convenient method, I recommend using a “mini” program similar to the one described.
here
Now I will describe how to do it manually. First stop XenAPI.
[ root @ xenserver / ] # /etc/init.d/xapi stop
Now open the file /var/xapi/state.db in your favorite editor:
[ root @ xenserver / ] # vi /var/xapi/state.db
Now search the file "admin1" (the name of the user you added). We are interested in these lines here:
other_config = "(('subject-name' 'admin1') ('subject-uid' 'u501') ('subject-gid' 'g501') ('subject-gecos'' ') (' subjec
t-displayname '' admin1 ') (' subject-is-group '' false ') (' subject-account-disabled '' false ') (' subject-account-expired '' false ') (' subject-account- locked '
'false') ('subject-password-expired' 'false')) " subject_identifier = " u501 " uuid = " 932d3540-d08c-bbf8-adf8-03c0f9aaaf43 " roles = "
As you can see, you can also change roles manually in the “roles =” section. We will change the role of our user from “pool-admin” to “read-only”:
roles = "('OpaqueRef: 7233b8e3-eacb-d7da-2c95-f2e581cdbf4e')"
Okay! Now run XenAPI back and check the result:
[ root @ xenserver / ] # /etc/init.d/xapi start
Starting xapi: .... start-of-day complete. [ OK ]
[ root @ xenserver / ] # xe subject-list
uuid ( RO ) : 932d3540-d08c-bbf8-adf8-03c0f9aaaf43
subject-identifier ( RO ) : u501
other-config ( MRO ) : subject-name: admin1; subject-uid: u501; subject-gid: g501; subject-gecos :; subject-displayname: admin1; subject-is-group: false ; subject-account-disabled: false ; subject-account-expired: false ; subject-account-locked: false ; subject-password-expired: false
roles ( SRO ) : read-only
That's all. You can run virtual machines back.
Thus, without violating the license, we were able to use RBAC with PAM authentication.
Hello everyone, thank you for your attention.
Source: https://habr.com/ru/post/135303/
All Articles