#17 RFE: no warning for tcb enabled system

main
closed-fixed
unSpawn
Rkhunter (37)
5
2014-08-01
2008-05-25
Dick Gevers
No

For increased security I enabled tcb - the alternative to shadow

For reference:
http://www.openwall.com/tcb/

http://www.builderau.com.au/program/linux/soa/Migrating-from-shadow-passwords-to-tcb-in-Linux/0,339028299,339269540,00.htm

http://freshmeat.net/projects/tcb-adduser/

Since this was implemented I get an rkhunter warning that seems not appropriate:

rkhunter -c -sk:
...
Checking for passwordless accounts [ Warning ]
...

rkhunter.log:
...
[10:34:46] Checking for passwordless accounts [ Warning ]
[10:34:46] Warning: No shadow/password file found.
...

This is due to the fact that the one /etc/shadow file has been replaced by separate /etc/tcb/<user>/shadow files.

I would like to propose that in some future version rkhunteris enhanced to check -- in case /etc/shadow is absent -- the integrity of the separate shadow files instead.

An example of such a user's shadow file reads:
quote
gnutester:$2a$Blablablablablablablablabla:14022:0:360:7:::
unquote

Thanks v.m. for your time.

Discussion

  • unSpawn
    unSpawn
    2008-05-27

    • labels: --> Rkhunter
    • assigned_to: nobody --> unspawn
     
  • unSpawn
    unSpawn
    2008-05-27

    Logged In: YES
    user_id=600864
    Originator: NO

    Thanks for adding Dick.

    I didn't look into it yet and I hope I may rely on you to provide some more information. Does /etc/tcb/ include an entry for every user known on the system? Or only users with a set password? Does TCB use pwck and grpck or equivalent tools?

    Best regards, unSpawn
    ---

     
  • Dick Gevers
    Dick Gevers
    2008-05-27

    Logged In: YES
    user_id=820199
    Originator: YES

    'Course.
    >Does /etc/tcb/ include an entry for every user known on the system?

    Yes, if there are x numbers of lines in /etc/passwd the number of directories in /etc/tcb will be equal to x; and the names of /etc/tcb/<foo> equal the names of the first data on each line of /etc/passwd.

    >Or only users with a set password?
    The shadow file of <username> within /etc/tcb/<username> has a content roughly equal to the one line for <username> in the old /etc/shadow file before conversion to tcb.

    I say 'roughly' because before (in my case on Mandriva Linux) crypt was used, with passwords stored starting with '$1$...', and when converting one defines in /etc/login.defs what type of encryption has the preference. For example blowfish, which would store (after a next password change by the user in question) the encrypted password in his 'shadow' file with <password> then starting with the string '$2a$...'. But while (s)he has not changed his password yet, the data continue to be stored starting with string '$1$...'

    >Does TCB use pwck and grpck or equivalent tools? It uses them, but pwck not for checking shadow. For ease of reference I will attach man pam_tcb.

     
  • Dick Gevers
    Dick Gevers
    2008-05-27

    Logged In: YES
    user_id=820199
    Originator: YES

    File Added: pam_tcb.8.gz

     
  • Dick Gevers
    Dick Gevers
    2008-05-27

    man(8) pam_tcb

     
    Attachments
  • Dick Gevers
    Dick Gevers
    2008-05-27

    Logged In: YES
    user_id=820199
    Originator: YES

    Thanks, I hope this attachments works okay: we have in Mandriva all manpages compressed with lzma, but as this may not be common yet I decompressed it and gzipped the result.

    Best regards, =Dick Gevers=

     
  • Logged In: YES
    user_id=1995630
    Originator: NO

    Dick - thank you for jumping into this!

    A few comments:

    1. It is critical to not access /etc/tcb/ subdirectories directly - doing so partly defeats the tcb security model. Instead, functions from libtcb must be used - please see the shadow-utils patch in Owl for usage examples.

    2. The password hashing method change is not directly related to the change from shadow to tcb. It is possible to use tcb with non-bcrypt ("$2a$") passwords, such as with FreeBSD-style MD5-based ones ("$1$"); it's just that since tcb depends on the API introduced with crypt_blowfish anyway, it'd be silly to not make use of bcrypt by default. Parameters to the pam_tcb module control which hashing method is used for newly set passwords, and with what iteration count.

    3. The CRYPT_* settings in /etc/login.defs, as supported by the Owl-derived shadow-utils patch, only affect group passwords (normally stored in /etc/gshadow), not user passwords (except on non-PAM'ified systems such as Slackware).

    4. The "tcb-adduser" reference is irrelevant; it's just a name collision.

     
  • John Horne
    John Horne
    2008-08-12

    Logged In: YES
    user_id=665381
    Originator: NO

    It is possible to specify a shadow file in the config file using the SHADOW_FILE option. Alternatively disable the 'group_accounts' test. This would at least get round the error being produced.

    I see no real problem in supporting tcb in RKH. Some questions though:

    Does each /etc/tcb/<foo> directory only contain a 'shadow' file? If so, why not just use /etc/tcb/<foo> as a file (the actual name being the userid)?

    I take it the /etc/passwd file is the same as on a typical shadowed system? That is, the password field is just an 'x', and the other fields, GID, users name (comment), etc are all present?

    > 1. It is critical to not access /etc/tcb/ subdirectories directly - doing
    > so partly defeats the tcb security model.
    >
    Why? We're not interested in the password itself, just whether one exists or not.

    I take it an account without a password has its entry in the shadow file as '::', just as it does on single shadow file systems?

    John.

     
  • Logged In: YES
    user_id=1995630
    Originator: NO

    John,

    > Does each /etc/tcb/<foo> directory only contain a 'shadow' file?

    It may also contain backup and temporary files.

    > why not just use /etc/tcb/<foo> as a file

    Most importantly, because the idea behind this tcb framework is to allow the users to change their passwords with minimal privileges (the passwd(1) program no longer needs to be SUID root), and to replace a shadow file atomically write privileges on the directory are needed. Clearly, we couldn't grant the users write privileges on /etc/tcb itself, which is shared for all users. As to atomic replacements, they are important even if the shadow files are per-user.

    > I take it the /etc/passwd file is the same as on a typical shadowed system?

    That's correct.

    As to my previous comment:

    "It is critical to not access /etc/tcb/ subdirectories directly - doing so partly defeats the tcb security model."

    The reason is precisely that those subdirectories are writable by other than root. In general, on Unix-like systems, it is unsafe to access directories writable by other users, unless special precautions are taken (such as those implemented in libtcb). Speaking of our tcb framework specifically:

    It is assumed that a vulnerability in passwd(1) or the like might exist - that's why we care to run those programs with reduced privileges rather than make them SUID-root. Thus, if such a vulnerability is exploited, a user may gain group "shadow" privileges. With our security model, this compromise is meant to be limited to the user's ability to bypass a possible password policy for their own account only - a rather minor issue.

    However, if there's another program on the system that violates our security model and accesses /etc/tcb/ subdirectories unsafely, or a sysadmin does that manually, such a compromise might lead to other nasties. For read accesses by the program/sysadmin, those nasties are usually/hopefully limited to DoS (e.g., the user might trigger a tape to be rewound or a system crash via (sym)links to device special files with side-effects on open and/or read - such devices do exist). For write accesses (e.g., if you were to change a user's password by direct write to their tcb shadow file), this may be a full-blown root compromise (you'd be tricked into overwriting any file on the system).

    I hope this helps.

    Alexander

     
  • John Horne
    John Horne
    2008-08-18

    Logged In: YES
    user_id=665381
    Originator: NO

    Fixed in CVS. I have done some testing of this, but really it requires testing by someone with a tcb shadow file system.

    John.

     
  • Dick Gevers
    Dick Gevers
    2008-08-19

    Logged In: YES
    user_id=820199
    Originator: YES

    Sorry, I tried to get cvs access according to the instructions that are here, but I get

    $ cvs -d:pserver:anonymous@rkhunter.cvs.sourceforge.net:/cvsroot login
    cvs [login aborted]: cannot get working directory: Permission denied

    otherwise I could try the cvs version on my tcb system.

     
  • Dick Gevers
    Dick Gevers
    2008-08-19

    Logged In: YES
    user_id=820199
    Originator: YES

    Aha; very good!

    Tested rkh 1.3.3 cvs from 19 AUG 2008 on tcb enabled Mandriva Linux Cooker and the enhancement is working as expected. Thanks very much!

    Please close the ticket when it suits you.

     
  • John Horne
    John Horne
    2008-08-19

    Logged In: YES
    user_id=665381
    Originator: NO

    Thanks for testing it. Closing call.

     
  • John Horne
    John Horne
    2008-08-19

    • milestone: --> main
    • status: open --> closed-fixed
     
  • John Horne
    John Horne
    2008-08-19

    Logged In: YES
    user_id=665381
    Originator: NO

    Forgot to add - FYI anonymous cvs seems to be working now :-)

     
  • Logged In: YES
    user_id=1995630
    Originator: NO

    John,

    Thank you for working on this. However, I notice that you have chosen to ignore my advice to not access the tcb shadow files directly. Is that possibly because rkhunter suffers from the problem and risk of accessing/reading files in directories writable by non-root anyway? (I don't know if that is the case as to the "reading" bit, but I find it likely.) Either way, at least a warning in the documentation would be in order. As it is, running rkhunter partly defeats the purpose of using our tcb suite in the first place. :-(

    I understand that it'd be difficult for you to use libtcb from a shell script. An alternative would be to use getpwent() from Perl, which goes via the tcb NSS module on a tcb-enabled system (which in turn uses libtcb), making tcb support fully transparent (so you would not need to check for tcb explicitly - you could do everything via getpwent() in Perl). A more obvious alternative, with similar properties, is to use getspent() or getspnam() from C - but, given that you currently have a script, you're likely to be more comfortable with Perl. Either way, tcb and libtcb specifics are hidden from you, and the same code works with regular /etc/shadow just as well.

    While I am at it, I suggest that you change /tmp/rkhunter-debug to /var/run/rkhunter-debug. Right now, you have a security hole allowing for local root compromise, although indeed the race condition is hard to trigger in practice.

    To those reading this: please note that this suggestion by no means constitutes a security review of rkhunter by me.

    Thanks,

    Alexander