Starting from version 1.4, RSBAC contains Virtual User Management (VUM), which is an extension to the existing User Management (UM).

Every user id now consists of a 32 Bit virtual set (vset) number and the old fashioned 32 Bit uid. The normal set of users is vset 0. It also exists, if VUM has been turned off in kernel configuration. All other vset numbers can be used as desired, there is no list of known sets.

User id u in vset s is consistently written as s/u. User name n in vset s is written as s/n. To login into set s, use s/username at the login prompt, e.g. 100/joe. All RSBAC tools accept the new notation of users. Every s/u has its own password, its own home directory, its own attributes, etc. RSBAC kernel logging uses the same notation, except that it does not write 0/n, but simply n for backwards compatibility and ease of use.

Every process has a current vset, so its s/u pair is taken from current vset and real uid. Access control, role changes etc. simply take the vset into account.

Vsets can be assigned to programs, e.g. an FTP daemon, to make a service run with a different set of users. Ever wanted to make sure that FTP attackers cannot crack passwords of SSH users? Well, separate the sets of users, done. On the fly, you can also get different access rights depending on the service you used for login.

Alternatively, a vset can also be given as parameter to the rsbac_jail command to start a program in a certain jail. As a general rule, every process with real uid u can change its vset from 0 (default) to another vset s, if it has the right to CHANGE_OWNER to s/u. As usual, this can be limited with AUTH (cap s/u), RC (CHANGE_OWNER right to type of s/u) or ACl (ACL at s/u).

By default, there is no way back to vset 0, and a process with another current vset than 0 cannot see any other vset's users. This restriction can be removed by a kernel config switch, in that case you will have to use access control to protect your vsets from being seen.

To make setups a bit easier, you can define default attribute values for a complete virtual user set s through the special user RSBAC_ALL_USERS, written as s/ALL. This value is used for all users in the set, which have no explicit value for that attribute. As an example, give all users in vset 10000 the RC type 10000 (through 10000/ALL) and only allow AUTHENTICATE to that user type for the FTP daemon running in that vset.

Also, AUTH now supports capabilities all/u1:all/u2 for u1 to u2 in all virtual sets. E.g. set AUTH cap all/0 on rsbac_jail so that it can CHANGE_OWNER to all virtual sets you specify in its command line.

To get your current set used for some user n, use auto/n or simply n. The PAM and NSS libraries always use auto vset, unless you write s/ before the user name or id.

For the follwing examples, you need a system with RSBAC 1.4 and the RSBAC PAM and NSS libraries active, see the UM page for instructions.

rsbac_usershow gives you a list of all users in a vset s with

rsbac_usershow -S s -l

and a list of all known users in all sets with

rsbac_usershow -S all -l

For a simple test as root, make a copy of /bin/bash to /tmp and use rsbac_fd_menu /tmp/bash to assign vset 1 to it. If you start that bash, it will say something like “I have no name” - user 1/root is not known.

As secoff (uid 0/400), copy group and user root from set 0 (the password will NOT be copied):

rsbac_groupadd -C root 1/root

rsbac_useradd -C root 1/root

Change 1/root's full name with

rsbac_usermod -c “Virtual root” 1/root

Now run that bash again - you have a name. Call

attr_get_user root full_name

to see your full name. You can copy more users as shown before, also change the uid number with -u or group number with -g, or create other users. If you get an error RSBAC_EINVALIDVALUE when copying or creating a user, one of the user groups is probably missing. Use rsbac_usershow for details about the user to be copied.

If you have CAP process hiding active, you will also notice that 1/root does not see other users' processes with ps ax - you have copied the user, not the attributes like cap_role. To change the cap_role, try as security

rsbac_user_menu 1/root

and change the cap_role to Administrator. Run ps ax in that bash again and see all processes. Simple, is it not?