[rsbac] kernel user management questions

[Amon Ott]

Hello everybody,

this is starting to become a FAQ. I am pretty glad about all the 
upcoming questions about the new User Management, because they show 
a lot of interest.

Official documentation has not yet been written, but will be as soon 
as I find the time. Volunteers are very welcome. I guess I will put 
this mail online soon.

On Donnerstag 03 Februar 2005 06:03, sftf at yandex.ru wrote:
> Hello !
>   Will you be so kind as to answer on couple questions?
>    1. What benefits of "in-kernel user management" against
>      traditional Linux user management subsystem?

The traditional Linux user management, specially the common 
passwd/shadow scheme with PAM, has several security problems:

1. PAM libraries running in process context:
The PAM libraries are mapped into every process, which has to 
authenticate users or change user accounts. This means that every 
single such process must have read or even write access to sensitive 
authentication data, and an exploit in only one of them reveals all 
this sensitive information to an attacker.  Not using PAM does not 
help here, because the process still needs the same access.

2. No granularity:
If a process has access to sensitive account or even authentication 
data of one user, it has access to the same for _all_ users in the 
system, even the administration accounts.

3. Changing passwords:
Because of 2., a program which allows password changes by the user 
(usually passwd), also has access to all passwords. An admin account 
which is allowed to set new passwords for normal users, who tend to 
forget their passwords, can do the same for any user - including 
other admins. This means this admin can get access to all other admin 
accounts, even if direct access is not allowed through RSBAC access 
control.

4. Password attacks:
As encrypted passwords are readable for too many processes, they can 
be guessed via dictionary attacks. Worse, the old crypt is easy to 
crack, and even the MD5 replacement is rumoured to be attackable with 
databases of precomputed MD5 strings.

5. Process choosing the uid to change to:
Any process with sufficient rights (CAP_SETUID and CAP_SETGID in 
Linux) can change to any uid it wants. Even the RSBAC v1.2.3 AUTH 
module functionality does not help against buggy login programs - 
they are supposed to setuid to a big range of uids, and the kernel 
cannot tell whether these have been authenticated or not.

6. Current implementation of passwd/shadow:
The current PAM implementation of the passwd/shadow scheme does not 
modify the files - it creates new ones and replaces the old ones with 
the new ones. There is nothing bad in avoiding inconsistencies in the 
absence of good locking - but it means the objects on disk constantly 
get new ids. As two different files have to be protected with 
different access rights (shadow must be inaccessible to normal users, 
passwd must be readable), it is almost impossible to protect them 
without race conditions.


Now, what is the difference in the new RSBAC User Management?

1. No process has direct access to user account or authentication 
data. All password checks etc. are done inside the kernel.  The new 
RSBAC PAM and NSS modules only call the appropiate system calls, so 
an attack against a process mapping them does not help at all.

2. Access rights to user account and authentication data are separate 
for every single account. There are different rights for access to 
them:
SEARCH: Get the mapping between uid and name
GET_STATUS_DATA: Read group, homedir, fullname or shell. The user 
usually needs this, other users usually do not.
READ: Get the user info usually placed in shadow: password validity, 
expiring etc. Usually only needed for account management.
WRITE: Change group, homedir, fullname, shell or the info usually in 
shadow.
GET_PERMISSIONS_DATA: Read the SHA1 encrypted password. Usually not 
needed, except for backup.
MODIFY_PERMISSIONS_DATA: Change the password. This is what an admin 
needs to reset a user password - but only for a limited set of users, 
and this right does not allow to read the previous password.
CREATE: Add a new user. How this is checked depends on the security 
model. E.g. RC roles have a default_user_create_type, so you need the 
right to this type.
DELETE: Delete a user account.
RENAME: Rename a user account.
Group protection is very similar, only the number of settings is 
smaller.

3. See 2.: You need MODIFY_PERMISSIONS_DATA for the particular user, 
not for all users.

4. Noone except the backup program can read the encrypted password, so 
offline password attacks are almost impossible. All an attacker can 
do is brute force through login, what will take a looooong time 
because of delays after each failure.

5. In combination with AUTH module, a login program can only setuid to 
the last authenticated uid. If it did not authenticate a uid against 
the kernel, setuid simply fails. To enable this, set AUTH 
auth_may_setuid to the new value last_auth_only or last_auth_and_gid. 
The latter allows to reach any group, because groups cannot be 
authenticated at login.
Furthermore, the UM exclusive mode only allows to setuid or setgid to 
uids and gids known to UM, so an attacker cannot use an uncontrolled 
uid, even if AUTH allows to setuid to any uid.

6. User and group data are always protected, so there is no such race 
condition.

>    2. What parts of traditional Linux user management subsystem
>      with "in-kernel user management" is no longer necessary
>      (/etc/passwd, /etc/group, shadow suit and so on...)?

You can remove the complete shadow suite with 
pam_unix, /etc/passwd*, /etc/shadow*, /etc/group*, /etc/gshadow*.

Still, I recommend keeping the PAM helper stuff, e.g. pam_cracklib.so. 
Just replace pam_unix.so in your PAM config files with pam_rsbac.so.

The rsbac_useradd and rsbac_groupadd commands can import existing 
accounts and groups, except for the passwords. These must be set 
manually for all accounts, RSBAC does not include password 
crackers. ;)
Sure this has to happen before you remove pam_unix and the files and 
before you change PAM and NSS config. It is sometimes necessary to 
rerun the import to get cross dependencies between groups and users 
right. You can check your groups and users with rsbac_groupshow and 
rsbac_usershow.

The old {user|group}{add|mod|del}, passwd programs with PAM and NSS 
support should continue working as before, but you can also replace 
them with rsbac_<oldname>. A symlink in /usr/local/bin works fine, if 
this dir is before /usr/sbin in the PATH setting. Additionally, if 
you have no PAM, you can replace the old login with rsbac_login, 
which only understands RSBAC UM.

>    3. How about programs and scripts wich relies on/work with
>       /etc/passwd, /etc/group directly ?

After testing on real server systems, I can gladly say that almost all 
Linux programs use the standard library calls to be compatible with 
all user/group schemes. Just install the RSBAC NSS and PAM modules 
from the admin tools contrib dir, change /etc/nsswitch.conf (replace 
compat in passwd, group, shadow by rsbac) and /etc/pam.d/* (replace 
pam_unix with pam_rsbac).
Then it simply works - if you granted the necessary access rights and 
imported the existing users, that is. :)

If you want to be careful, you can run passwd/shadow and RSBAC UM in 
parallel for a while, before you turn the first off: In nsswitch.conf 
change "compat" to "compat rsbac", in /etc/pam.d/* add "<type> 
sufficient pam_rsbac.so" before the pam_unix.so line.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde geschreddert...
Dateiname   : nicht verf?gbar
Dateityp    : application/pgp-signature
Dateigr??e  : 189 bytes
Beschreibung: nicht verf?gbar
URL         : http://www.rsbac.org/pipermail/rsbac/attachments/20050203/e7120baf/attachment.bin