The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

tcb (5)
  • tcb (5) ( Русские man: Форматы файлов )
  • >> tcb (5) ( Linux man: Форматы файлов )
  •  

    NAME

    tcb - alternative password shadowing scheme
     
    

    PROBLEM

    With the traditional password shadowing scheme, password hashes and password aging information of all users is stored in one file, /etc/shadow. Therefore, if a process requires access to information on a single user, it is forced to possess privileges which are sufficient to access data on all users. This is a design flaw, which is most clearly visible in the case of passwd(1) utility. Let's assume that unprivileged users are to be allowed to change their own passwords. Whatever permissions are assigned to /etc/shadow, passwd(1), invoked by unprivileged user U, must be able to modify the contents of this file. If malicious user U finds a way to control the passwd(1) process (with the help of a buffer overflow or another bug in the passwd(1) code, in the libraries it uses, or in the kernel), the user will be able to change passwords of all users and thus obtain full control over the system.  

    SOLUTION

    The solution is straightforward - each user is assigned its own, separate shadow-style file. User U's shadow file is owned by U, so passwd(1) invoked by U does not require superuser privileges.

    The directory where all users' shadow files reside is /etc/tcb:

    drwx--x---    2 root     shadow       1024 Jul  4 01:18 /etc/tcb
    For each user, there is a directory under
    /etc/tcb
    with appropriate ownership and permissions:
    
    
    # ls -l /etc/tcb
    total 2
    drwx--s---    2 root     auth         1024 Jul  4 01:18 root
    drwx--s---    2 user     auth         1024 Jul  4 01:18 user
    and so on.
    Each of the directories contains a shadow file for just the
    appropriate user:
    
    
    # ls -l /etc/tcb/user
    total 1
    -rw-r-----    1 user     auth           91 Jul  4 01:18 shadow
    The per-user directories are also used as scratch space for temporary
    and lock files which are needed during password change.
    
     

    ADVANTAGES

    This design has the following benefits:
    1.
    passwd(1) needs to be SGID to group shadow only, not SUID to root. chage(1) and /usr/lib/chkpwd/tcb_chkpwd are SGID to group shadow too, which with the tcb scheme means they only possess the privilege to access the user's own shadow file entry. A bug in one of these utilities may at most give a malicious user direct access to their own shadow file.
    2.
    If a process needs to possess read-only access to all shadow files, it is sufficient to assign it supplementary groups "shadow" and "auth".
    3.
    On systems supporting NSS, this scheme is completely transparent to applications which need read-only access to shadow file information. The libnss_tcb library implements getspnam(3) and other related functions with their traditional semantics. Password changing is provided by pam_tcb(8), a PAM module.

    See the tcb_convert(8) manual page for instructions on how to enable the tcb scheme seamlessly.  

    DISADVANTAGES

    Honestly, there are a few minor ones:
    1.
    It is impractical to lock all of the shadow database (see tcb_unconvert(8)).
    2.
    Giving a process read-only access to all shadow files as described above has the side-effect of also giving it read-write access to the shadow entry of the (pseudo-)user it is running as.
    3.
    It is impossible to give a process privileges sufficient for read-only access to a single shadow file only, without also having it actually run as the user.
    4.
    The user management tools initially required heavy patching to support the tcb scheme.
     

    WORKAROUNDS FOR FILESYSTEMS LIMITS

    In case of ext2fs, the maximum number of hardlinks to a single file is limited to 32000. Therefore, with this filesystem, there can be at most 31998 directory entries in /etc/tcb and, with the filesystem layout described above, at most 31998 users.

    The workaround: a tcb directory of user U can be located not only in /etc/tcb, but also in /etc/tcb/:some/path. In the latter case, there should be a symlink /etc/tcb/U -> /etc/tcb/:some/path/U.

    Starting with tcb 0.9.8, directories which match the shell pattern /etc/tcb/:* are not treated as per-user directories by tcb libraries. These directories are reserved to hold symlinked per-user directories, and for other purposes.

    By default, shadow suite utilities create directory entries directly in /etc/tcb; if one expects more than 31998 users on the system, one can switch on the symlink creation anytime by editing login.defs(5) config file.  

    AUTHORS

    The tcb suite was implemented for Openwall GNU/*/Linux by Rafal Wojtczuk <[email protected]> and Solar Designer <[email protected]>. pam_tcb is meant to be backwards-compatible with pam_unix, therefore some design decisions are cloned from pam_unix. Also certain less critical code fragments, as well as some of the code layout, are taken from the Linux-PAM implementation of pam_unix. The names of contributors to pam_unix can be found under orig_copyright/ in source distribution of the tcb suite.  

    SEE ALSO

    login.defs(5), pam_tcb(8), tcb_convert(8)


     

    Index

    NAME
    PROBLEM
    SOLUTION
    ADVANTAGES
    DISADVANTAGES
    WORKAROUNDS FOR FILESYSTEMS LIMITS
    AUTHORS
    SEE ALSO


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру