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 provides good functionality “for free”.
Therefore, many decisions are made on the Free version without Enterprise features.
And the number of "paid" chips includes authorization using LDAP with the ability to differentiate user rights.
Yes, you heard right. In free XenServer, all users are equal. That is, they have the role of Pool Admin.
Let's try to figure out how we can “protect” the hypervisor in the free version?




According to Citrix’s policy, XenServer versions called Free and Advanced are essentially single-user. That is, any user of the system will be perceived by XenAPI as a user with the PoolAdmin role. Which negatively affects the process of servicing the hypervisor from the point of view of information security.
There are at least two ways to solve this problem without purchasing an Enterprise version.
Let's start with the first, more simple and understandable.

We will limit the circle of users of the system with access to XenApi.
To do this, first create a file:

[root @ xenserver /] # cd / etc /
[root @ xenserver etc] # vi xapi_allow

In it we will list the users allowed to manage the hypervisor.

root
admin1
admin2
admin3

Thanks to the XenSource guys for what they did: this is the xapi PAM module for controlling access to the hypervisor. But by default, it is used in the system a little differently than we need.
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 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
 

Now, in order for the user to connect to the XenAPI, it is necessary that the record about him be contained in the xapi_allow file. Now it’s worth restricting access to this file:

[root @ xenserver /] # chmod 600 / etc / xapi_allow

Excellent! Now we can “prevent” users of the system that we do not want to control the hypervisor. Under the Free / Advanced license, perhaps this is all that can be done.
But, you can go further. You can enable the use of RBAC systems. To do this, we need to enable external authentication in the system. Here we run into a license restriction, and cannot 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 this without violating the license.

To get started, turn off all 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): The VM Power Administrator role has full access to VM and template management and can choose where to start VMs and use the dynamic memory control and VM snapshot features
 
 
uuid (RO): aaa00ab5-7340-bfbc-0d1b-7cf342639a6e
name (RO): vm-admin
description (RO): The VM Administrator role can manage VMs and templates
 
 
uuid (RO): fb8d4ff9-310c-a959-0613-54101535d3d5
name (RO): vm-operator
description (RO): The VM Operator role can use VMs and interact with VM consoles
 
 
uuid (RO): 7233b8e3-eacb-d7da-2c95-f2e581cdbf4e
name (RO): read-only
description (RO): The Read-Only role can log in with basic read-only access
 
 
uuid (RO): b9ce9791-0604-50cd-0649-09b3284c7dfd
name (RO): pool-operator
description (RO): The Pool Operator role manages host- and pool-wide resources, including setting up storage, creating resource pools and managing patches, high availability (HA) and workload balancing (WLB)
 
 
uuid (RO): 0165f154-ba3e-034e-6b27-5d271af109ba
name (RO) : pool-admin
description (RO): The Pool Administrator role has full access to all features and settings, including accessing Dom0 and managing subjects, roles and external authentication

These are the roles that you can use on your server.
Now add user entities.

[root @ xenserver /] # xe subject-add subject-name = admin1
932d3540-d08c-bbf8-adf8-03c0f9aaaf43

And make sure everything is done correctly and your new subject has received the pool-admin rights 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 set 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 database file .
As a convenient method, I recommend using "mini" programs similar to those 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 “admin1” file (the name of the user you added). We are interested in these lines:

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 see, you can also change roles manually in the "roles =" section. Change our user role 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 start virtual machines back.
Thus, without violating the license, we were able to use RBAC with authentication through PAM.
Hello everyone, thank you for your attention.