Re: User?s and Shells

From: Scott Gifford (sgifford@suspectclass.com)
Date: 12/21/02

  • Next message: Small, Jim: "RE: User?s and Shells"
    To: "'focus-linux@securityfocus.com'" <focus-linux@securityfocus.com>
    From: Scott Gifford <sgifford@suspectclass.com>
    Date: 21 Dec 2002 03:28:42 -0500
    
    

    Brian Hatch <focus-linux@ifokr.org> writes:

    > > I'm wondering why I would want that - until now nobody could give me a
    > > good argument although everybody learns to remove the shells :-(
    > >
    > > * If I give my users a disabled password, they cannot? login via passwd
    > > based ssh/ftp/pop3 etc.
    >
    > Not true. Say you disable the passwd (put "*" in /etc/shadow
    > file, for example) but they have already enabled SSH identity
    > authentication so they never use actual password authentication.
    > You think they can't log in because there's no legal password,
    > but SSH lets them in before it gets there.

    In the past, many people have had similar issues using the r*
    commands. If the user has a shell and ssh or any of the r* commands
    are running, you have to protect the user's home directory from
    writing just as diligently as you would have to protect their
    passwords, and a nonexistent shell in /etc/passwd provides another
    layer of protection.

    And it's not just a matter of the user creating a .rhosts file before
    their password is disabled. Writing to a home directory is one way to
    escalate privileges; for example, your news user was:

        news:x:9:13:news:/etc/news:

    . If news has write permission in /etc/news, a bug in your newsserver
    that provides only the ability to create arbitrary files owned by news
    can suddenly be leveraged into a shell on your system if you have ssh
    or r* running and news has a real shell.

    ----ScottG.