Re: PATH variable in zip-slackware 2.0.35

From: Patrick J. Volkerding (gonzoat_private)
Date: Mon Jan 04 1999 - 13:02:54 PST

  • Next message: Scott: "Re: SUN almost has a clue! (automountd)"

    On Mon, 4 Jan 1999, Rattle wrote:
    > As far as I can remember, "/usr/andrew" and "." have been in the PATH
    > on every version of Slackware I have ever installed.  Which probably
    > meants its even in pre 2.0 releases.
    >
    > While the presence "/usr/andrew" is (in most cases) nothing more than
    > "clutter", having "." is your path is a very common mistake admins make.
    > Mainly because people can be to lazy to type ./configure when installing
    > packages.  As previously mentioned, this can is used by the common script
    > kiddie to easily make a suid shell or other 4xxx toy for himself.
    >
    > Many a machine has been cracked by someone inserting a script named "ls"
    > in the /tmp dir.
    
    I'm catching a bit of flamage on this one (and might change what's always
    been the default), but the here are the rules I have always gone by:
    
    1.  If you tend to type without thinking at the '#' prompt, tend to input
        a lot of typos, or are just really paranoid in general, you might not
        want '.' in your path at all.
    
    2.  If you put '.' first in your $PATH, you are asking for trouble.
        Obviously, it would need to be first for the 'ls' kiddie script in
        /tmp attack mentioned above to work.
    
    3.  If you put '.' last in the $PATH, it's a minimal risk, IMHO.  If you
        use normal care in user-writable directories you're not likely to ever
        have a problem.  Attacks would depend on specific typos in specific
        user-writable directories matching the filename of an attack script.
        This would be extremely rare.
    
        However, if you fall into catagory (1), you can change the default
        $PATH easily. It's hardly a hidden setting.
    
    > Also, there are hooks in various Slackware startup scripts (ie:
    > /etc/rc.d/rc.inet2) to startup various daemons that are not installed by
    > default.  The first one that comes to mind is sshd.  While this is not a
    > security risk (as it only looks to the dirs "/usr/sbin" and
    > "/usr/local/sbin").  I may be mistaken (Its kinda late here.. heh), but I
    > can sware that it is not commented out by default.  As I said, not a
    > blatent security risk, but if you have sshd installed, but don't want it
    > to run..  You may want to comment that out.  (And if you don't use
    > ssh/scp, you should..)
    
    This is not a security risk, or any problem at all in fact.  How could it
    be?  Only root can install things in /usr/sbin and /usr/local/sbin.
    
    My $0.02, :)
    
    Patrick J. Volkerding
    Slackware Linux maintainer
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:20 PDT