[tac_plus] Full AAA logging / supported configuration

Sean spedersen.lists at gmail.com
Wed Sep 14 00:04:17 UTC 2016


No, different systems and different authentication schemas. Root access on these systems is not tied to the same system as password authentication. Someone who is root on these systems is not necessarily the same people who would have the ability to reset the password(s) of individual users. Even then, they would not see them in clear text. 

Don’t assume I’m letting untrusted persons have root; I’m not. Someone who is trusted and has root on these systems doesn’t need to see another user’s clear text passwords under any circumstances. 

With so many ways and means to authenticate and authorize someone, and considering the integration into systems that can provide such (local, LDAP, RADIUS, etc. etc.) a clear text password It should not be in the debug logs. 

Someone pops one server with tac_plus running on it, bounces the service and enables -d 256, sits pretty while people log into network devices, then has a nice list of usernames and passwords all in clear text to start harming the rest of the network and the systems on it.

On 9/13/16, 3:23 PM, "tac_plus on behalf of Alan McKinnon" <tac_plus-bounces at shrubbery.net on behalf of alan.mckinnon at gmail.com> wrote:

    On 13/09/2016 15:22, Sean wrote:
    > So the logging occurs once it’s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted?
    >
    > I don’t like the idea that someone else with sudo / root can sniff someone else’s passwords in clear text. ☹
    
    What's the point? If the user is root, they can make any user's password 
    be anything they want it to be
    
    Rule #1: the root user can always get around any security measure you 
    put in place. Mostly because for root their ARE no security measures in 
    place.
    
    Why are you letting untrusted persons have root access anyway? Apart 
    from generally being a bad idea, it also unticks all the check boxes so 
    beloved of auditors.
    
    
    >
    > On 9/12/16, 4:41 PM, "heasley" <heas at shrubbery.net> wrote:
    >
    >     Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean:
    >     > Then I misspoke. I thought the key was used for authentication; I didn’t realize it was also being used to encrypt the packets.
    >     >
    >     > I’ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled.
    >
    >     only data on the wire in encrupted
    >
    >
    >
    >
    > _______________________________________________
    > tac_plus mailing list
    > tac_plus at shrubbery.net
    > http://www.shrubbery.net/mailman/listinfo/tac_plus
    >
    
    _______________________________________________
    tac_plus mailing list
    tac_plus at shrubbery.net
    http://www.shrubbery.net/mailman/listinfo/tac_plus
    





More information about the tac_plus mailing list