Re: Strange command histories in hacked shell history

From: Bill Vermillion (bv_at_wjv.com)
Date: 12/20/04

  • Next message: Brett Glass: "chroot-ing users coming in via SSH and/or SFTP?" 
    Date: Mon, 20 Dec 2004 12:18:36 -0500
To: freebsd-security@freebsd.org

    While normally not able to pour water out of a boot with
    instructions on the heel, on Mon, Dec 20, 2004 at 10:56
    our dear friend Gerhard Schmidt uttered this load of codswallop:

    > On Fri, Dec 17, 2004 at 09:53:15AM -0500, Bill Vermillion wrote:

    [much deleted - wjv]

    > > Can anyone explain why su does not use the UID from the login
    > > instead of the EUID ? It strikes me as a security hole, but I'm no
    > > security expert so explanations either way would be welcomed.

    > I'm not a security expert, but if someone has the
    > Username/Password for an Account that can su to root. Where is
    > the point of disallowing him to su to this user and than to su.
    > You can?t prevent him form directly logging in as this User
    > an than use su. Therefore there is no gain in security just a
    > drawback in usefulness. I use this often to get a rootshell on
    > an Xsession from an user who can't su to root.

    You can limit the access for the person who has wheel/su
    privledges by running sshd and then permitting connections only
    from certain IPs or IP blocks. So another person is severely
    restricited from logging in as this user even if they have cracker
    that persons password. But once the craccker is in the system they
    can attempt breaking the password on a local basis, and the attack
    the root system.

    I think the comment one other person made about limiting the su
    stack to 1, so that you can not su to an account and then su to
    another account is a good approach.

    Considering the HUGE abount of attempted SSH logins I see on my
    servers from all over the world, with most coming from Korea,
    China, and lately Brazil, to add to those from Germany and Russia
    [just some I recall from the whois queries] andthing we can do
    to improve the security is a step forward.

    In server environments security far outweighs all other
    considerations IMO.

    Bill 

    -- 
Bill Vermillion - bv @ wjv . com
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Next message: Brett Glass: "chroot-ing users coming in via SSH and/or SFTP?"

    Relevant Pages

    • Re: Of mice and men
      ... any more than bank security is voluntary by the customers. ... With their own account, and guest accounts set up, I no longer have to worry about someone else screwing my work tools up. ... There are many programs that have in the past been used to exploit Linux - programs running as "root" even though you are just a plebian user. ... If you ask to run a program that uses root privleges "as a plebian user" it will tell you that you do not have disk access. ...
      (comp.lang.cobol)
    • Re: hi all..
      ... If you somehow had access to my account right now, ... install an effective key logger without root. ... Of course, if I have sudo ... the security of your system you should just reinstall. ...
      (Fedora)
    • Re: How to Configure Qmail on Fedora Core 1 Server
      ... since the user foo would not have root privledges. ... that account is cracked they still are restricted on privileges. ... The security issue with reading mail as root via pop3 or imap is the ...
      (Fedora)
    • Re: Choosing a distribution
      ... potentially be cracked and hence give the intruder root access. ... However, with sudo you can ... and with a root account you use a different password that now needs ... You're claiming "increased" security by use of a root ...
      (Ubuntu)
    • Re: Renaming root account
      ... It's not a *good* idea because it's security through obscurity. ... executables use "uid 0" vs "root", so changing the name of the account ... the attacker does not need to know what access he is trying to get (eg. ... root or non-root), only what service her/his attack will use as a vector. ...
      (FreeBSD-Security)