Secure $PATH for regular user - Security

This is a discussion on Secure $PATH for regular user - Security ; Hi, I remember, but can not find it, that for non root user it's advised not include /sbin and /usr/sbin in $PATH. Is it right? If yes, I'll be glad to find a reference to security audit indicating it, as ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: Secure $PATH for regular user

  1. Secure $PATH for regular user

    Hi,

    I remember, but can not find it, that for non root user it's advised
    not include /sbin and /usr/sbin in $PATH. Is it right?

    If yes, I'll be glad to find a reference to security audit indicating
    it, as a proof to my manager

    Thanks
    Dmitry


  2. Re: Secure $PATH for regular user

    On 29 Oct, 10:37, Dmitry wrote:
    > Hi,
    >
    > I remember, but can not find it, that for non root user it's advised
    > not include /sbin and /usr/sbin in $PATH. Is it right?
    >
    > If yes, I'll be glad to find a reference to security audit indicating
    > it, as a proof to my manager
    >


    I've never came across such a recommendation - all the programs I can
    think of in these directories should have additional controls to
    prevent non-root users abusing them, and may be needed to see the
    state of the system (e.g. ifconfig, mount, fuser...). And your
    recommendation sounds like Security by obscurity which is generally
    considered a bad thing.

    C.



  3. Re: Secure $PATH for regular user

    On Mon, 2007-10-29 at 10:37 +0000, Dmitry wrote:
    > Hi,
    >
    > I remember, but can not find it, that for non root user it's advised
    > not include /sbin and /usr/sbin in $PATH. Is it right?
    >
    > If yes, I'll be glad to find a reference to security audit indicating
    > it, as a proof to my manager
    >
    > Thanks
    > Dmitry
    >


    Actually the converse is true. The root user should never inherit
    the PATH of a normal user as that could lead to a compromise.

    Do normal users NEED /sbin and /usr/sbin in their PATH? Normally, no.
    However some tools, like ifconfig, can display useful information even
    to a normal user and it's located in /usr/sbin.



  4. Re: Secure $PATH for regular user

    On Mon, 29 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <1193654274.587361.265790@v3g2000hsg.googlegroups.c om>, Dmitry wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    >I remember, but can not find it, that for non root user it's advised
    >not include /sbin and /usr/sbin in $PATH. Is it right?


    It's not that it's not advised, it's more a tradition. This is a long
    story - but generally, the stuff in /sbin and /usr/sbin are not
    normally used/needed by the average user. Those few commands that a
    user might need, such as 'arp', 'ifconfig', and 'route' can be accessed
    using the full path to the command. Example:

    [compton ~]$ echo $PATH
    /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/ibuprofin/bin
    [compton ~]$ route -n
    bash: route: command not found
    [compton ~]$ /sbin/route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 189948 eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 388 lo
    0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 12673 eth0
    [compton ~]$

    >If yes, I'll be glad to find a reference to security audit indicating
    >it, as a proof to my manager


    I've no idea why there would be. Further, any auditor giving that kind
    of advice is totally clueless and should be shot immediately. [1]

    [compton ~]$ /sbin/route add -net 192.168.3.0 gateway 192.168.1.11
    SIOCADDRT: Operation not permitted
    [compton ~]$

    Notice that while I can run the command to _GET_ information, I can NOT
    run the command to _change_ anything. That's because any command that
    is "sensitive" checks the UID of the person running the command, and
    won't do "sensitive" or "critical" things unless the person is root.

    Setting the PATH is a service of the shell, and the user can set the
    PATH as they desire.

    If letting your users see commands in /sbin/ or /usr/sbin/ is the
    problem, you might change the permissions of that directory, but don't
    be surprised if this causes other problems. You can also use a number
    of shells in a restricted mode - that prevents users from changing
    directories, or running any command with a '/' in it. Depending on
    your situation, this may be your answer, or it may prevent your users
    from doing useful work.

    Finally, if you don't trust your users, why are they allowed on your
    system in the first place?

    Old guy

    [1] A friend tells of a "security auditor" who demanded the 'administrator'
    password on a Solaris system ("what account???") so that he could use his
    floppy full of programs (on hardware that lacks a floppy drive), and who
    told the friend not to worry because the floppy had been virus scanned.
    The friend was nice enough to tell everyone he knew 1) the name of the
    so-called "security auditor", 2) the name of the company the idiot
    worked for, and 3) the name of the (now) ex-employee that hired these
    idiots. Rote stupidity does not enhance security.

  5. Re: Secure $PATH for regular user

    On 29 Oct, 10:37, Dmitry wrote:
    > Hi,
    >
    > I remember, but can not find it, that for non root user it's advised
    > not include /sbin and /usr/sbin in $PATH. Is it right?
    >
    > If yes, I'll be glad to find a reference to security audit indicating
    > it, as a proof to my manager


    Under most Linux systems I've seen, there's a widget in /etc/profile
    that *provides* /sbin and /usr/sbin for the root user, and does not do
    so for non-root users. This is irritating if you use sudo to run
    things as root, since programs from the sbin directories are not in
    the PATH as expected.

    Now, the "." and the "~/bin" directories, *those* do not belong in the
    default PATH.


  6. Re: Secure $PATH for regular user

    On Tue, 2007-10-30 at 06:17 -0700, Nico wrote:
    > On 29 Oct, 10:37, Dmitry wrote:
    > > Hi,
    > >
    > > I remember, but can not find it, that for non root user it's advised
    > > not include /sbin and /usr/sbin in $PATH. Is it right?
    > >
    > > If yes, I'll be glad to find a reference to security audit indicating
    > > it, as a proof to my manager

    >
    > Under most Linux systems I've seen, there's a widget in /etc/profile
    > that *provides* /sbin and /usr/sbin for the root user, and does not do
    > so for non-root users. This is irritating if you use sudo to run
    > things as root, since programs from the sbin directories are not in
    > the PATH as expected.


    The correct answer for those cases is to use the -i option (on newe
    versions of sudo). The security risk is with sudo since it does leave
    the PATH alone, which is exactly the huge security risk mentioned in my
    other post in this thread. Again, has nothing to do with the what the
    OP was asking...


    >
    > Now, the "." and the "~/bin" directories, *those* do not belong in the
    > default PATH.
    >


    But sudo inherits the PATH of the current user invoking sudo. This is
    VERY dangerous. Something to remember. e.g. Let's say your PATH is
    PATH=/myuglynasty/bin:$PATH and inside that myuglynasty/bin directory
    has fairly open permissions and a vicious copy of a common executable.
    Hopefully you can see the problem.




  7. Re: Secure $PATH for regular user

    On Tue, 30 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <1193750234.632859.264120@19g2000hsx.googlegroups.c om>, Nico wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    >Under most Linux systems I've seen, there's a widget in /etc/profile
    >that *provides* /sbin and /usr/sbin for the root user, and does not
    >do so for non-root users.


    /etc/profile is a configuration file, and I've never noticed it being
    standardized across distributions. /etc/profile is sourced when a
    Bourne style shell is a "login" shell, but (with few exceptions such
    as the new release of Mandriva) /etc/profile is not sourced in a GUI
    login. In text based logins (that use /bin/login), the PATH is often
    initially set by /bin/login, while a typical GUI sets the PATH in the
    login manager:

    [selene ~]# strings /bin/login | grep bin:
    /usr/local/bin:/bin:/usr/bin
    /sbin:/bin:/usr/sbin:/usr/bin
    [selene ~]# strings /usr/X11R6/bin/xdm | grep bin:
    /sbin:/usr/sbin:/bin:/usr/bin
    /usr/local/bin:/bin:/usr/bin
    [selene ~]#

    The startup scripts for the login shell may then be used to replace
    or alter the PATH (recall there are individuals who use a C shell
    such as /bin/tcsh and friends - none of which know about /etc/profile).

    >This is irritating if you use sudo to run things as root, since
    >programs from the sbin directories are not in the PATH as expected.


    Minor quibble - policy at every place I've seen sudo used was to
    train the sudoers to ALWAYS run the commands with full PATHname,
    even if the desired binary is in the users PATH. Admittedly, the
    documentation that comes with sudo doesn't stress this elementary
    precaution. Untrained users (the typical 'home' user) often don't
    understand this - but then, they also lack a lot of basic security
    concepts as well.

    >Now, the "." and the "~/bin" directories, *those* do not belong in
    >the default PATH.


    The dot (".") in the PATH (or ending the PATH with a colon ":" which
    has the same effect) I can agree should not be in the PATH. Why do
    you feel that the individual user's home/bin directory should not be
    in the PATH. What exploit are you assuming is possible due to this?
    Most sane setups do not have that directory writable by other than
    the owner, and placing nasties there requires the same elevated
    permissions that are needed to replace system binaries in /bin/ or
    similar. Hence, if they can screw up the users ~/bin, they can also
    screw the entire system. What's the point?

    Old guy

  8. Re: Secure $PATH for regular user

    Moe Trin wrote:

    > The dot (".") in the PATH (or ending the PATH with a colon ":" which
    > has the same effect) I can agree should not be in the PATH. Why do
    > you feel that the individual user's home/bin directory should not be
    > in the PATH. What exploit are you assuming is possible due to this?
    > Most sane setups do not have that directory writable by other than
    > the owner, and placing nasties there requires the same elevated
    > permissions that are needed to replace system binaries in /bin/ or
    > permissions that are needed to replace system binaries in /bin/ or
    > similar. Hence, if they can screw up the users ~/bin, they can also
    > screw the entire system. What's the point?


    huh system directories are owned and writeable only by root
    directories in the home directory are writeable by the user of that
    directory
    meaning: in case of system dirs the euid has to be root to dump
    malicious executables
    in case of the home dir, the euid can be root or the owner (normal user).
    this means a exploited program running as a normal user can dump an
    executable
    in that directory, if the attacker puts common unix executables in there
    and if that dir is put in PATH
    like this PATH="~/bin:$PATH". then you can be royally ****ed, this is
    especially true if your sudo is configured very pragamatically eg the
    user is part of a group or can sudo anything without PASSWORD eg:
    ALL=(ALL) NOPASSWD:ALL

    now the attacker instead of actively trying to attack local running root
    processes
    or using exploits on executable SUID programs can just replace a common
    tool like
    iptables,lspci,ifconfig,kill,killall,... with a version that does the
    same but also launch a reverse shell running as ROOT
    now he can just go to bed and wait till the unknowing user uses sudo
    (unknowingly ) on the malicious binary

    yes this is dangerous !




  9. Re: Secure $PATH for regular user

    goarilla wrote:
    > Moe Trin wrote:
    >
    >> The dot (".") in the PATH (or ending the PATH with a colon ":" which
    >> has the same effect) I can agree should not be in the PATH. Why do
    >> you feel that the individual user's home/bin directory should not be
    >> in the PATH. What exploit are you assuming is possible due to this?
    >> Most sane setups do not have that directory writable by other than
    >> the owner, and placing nasties there requires the same elevated
    > > permissions that are needed to replace system binaries in /bin/ or
    > > permissions that are needed to replace system binaries in /bin/ or
    > > similar. Hence, if they can screw up the users ~/bin, they can also
    > > screw the entire system. What's the point?

    >
    > huh system directories are owned and writeable only by root
    > directories in the home directory are writeable by the user of that
    > directory
    > meaning: in case of system dirs the euid has to be root to dump
    > malicious executables
    > in case of the home dir, the euid can be root or the owner (normal user).
    > this means a exploited program running as a normal user can dump an
    > executable
    > in that directory, if the attacker puts common unix executables in there
    > and if that dir is put in PATH
    > like this PATH="~/bin:$PATH". then you can be royally ****ed, this is
    > especially true if your sudo is configured very pragamatically eg the
    > user is part of a group or can sudo anything without PASSWORD eg:
    > ALL=(ALL) NOPASSWD:ALL
    >
    > now the attacker instead of actively trying to attack local running root
    > processes
    > or using exploits on executable SUID programs can just replace a common
    > tool like
    > iptables,lspci,ifconfig,kill,killall,... with a version that does the
    > same but also launch a reverse shell running as ROOT
    > now he can just go to bed and wait till the unknowing user uses sudo
    > (unknowingly ) on the malicious binary
    >
    > yes this is dangerous !
    >
    >
    >


    my apologies for the incorrect quoting

  10. Re: Secure $PATH for regular user

    goarilla wrote:
    > goarilla wrote:
    >> Moe Trin wrote:
    >>
    >>> The dot (".") in the PATH (or ending the PATH with a colon ":" which
    >>> has the same effect) I can agree should not be in the PATH. Why do
    >>> you feel that the individual user's home/bin directory should not be
    >>> in the PATH. What exploit are you assuming is possible due to this?
    >>> Most sane setups do not have that directory writable by other than
    >>> the owner, and placing nasties there requires the same elevated
    >> > permissions that are needed to replace system binaries in /bin/ or
    >> > permissions that are needed to replace system binaries in /bin/ or
    >> > similar. Hence, if they can screw up the users ~/bin, they can also
    >> > screw the entire system. What's the point?

    >>
    >> huh system directories are owned and writeable only by root
    >> directories in the home directory are writeable by the user of that
    >> directory
    >> meaning: in case of system dirs the euid has to be root to dump
    >> malicious executables
    >> in case of the home dir, the euid can be root or the owner (normal user).
    >> this means a exploited program running as a normal user can dump an
    >> executable
    >> in that directory, if the attacker puts common unix executables in
    >> there and if that dir is put in PATH
    >> like this PATH="~/bin:$PATH". then you can be royally ****ed, this is
    >> especially true if your sudo is configured very pragamatically eg the
    >> user is part of a group or can sudo anything without PASSWORD eg:
    >> ALL=(ALL) NOPASSWD:ALL
    >>


    damn it i forgot the attacker could simply sudo

    >> now the attacker instead of actively trying to attack local running
    >> root processes
    >> or using exploits on executable SUID programs can just replace a
    >> common tool like
    >> iptables,lspci,ifconfig,kill,killall,... with a version that does the
    >> same but also launch a reverse shell running as ROOT
    >> now he can just go to bed and wait till the unknowing user uses sudo
    >> (unknowingly ) on the malicious binary
    >>
    >> yes this is dangerous !
    >>
    >>
    >>

    >
    > my apologies for the incorrect quoting


  11. Re: Secure $PATH for regular user

    I demand that goarilla may or may not have written...

    [snip]
    > my apologies for the incorrect quoting


    You forgot about the bad formatting. ;-)

    --
    | Darren Salt | linux or ds at | nr. Ashington, | Toon
    | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
    | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

    stick: n. A boomerang that doesn't work.

  12. Re: Secure $PATH for regular user

    Darren Salt wrote:
    > I demand that goarilla may or may not have written...
    >
    > [snip]
    >> my apologies for the incorrect quoting

    >
    > You forgot about the bad formatting. ;-)
    >



  13. Re: Secure $PATH for regular user

    On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <4727c4d7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:

    >goarilla wrote:


    >> goarilla wrote:


    >>> Moe Trin wrote:


    >>>> The dot (".") in the PATH (or ending the PATH with a colon ":" which
    >>>> has the same effect) I can agree should not be in the PATH.


    I should point out that the ending colon trick is not a POSIX feature.

    >>>> Most sane setups do not have that directory writable by other than
    >>>> the owner, and placing nasties there requires the same elevated
    >>>> permissions that are needed to replace system binaries in /bin/ or
    >>>> permissions that are needed to replace system binaries in /bin/ or
    >>>> similar. Hence, if they can screw up the users ~/bin, they can also
    >>>> screw the entire system. What's the point?


    >>> huh system directories are owned and writeable only by root
    >>> directories in the home directory are writeable by the user of that
    >>> directory
    >>> meaning: in case of system dirs the euid has to be root to dump
    >>> malicious executables
    >>> in case of the home dir, the euid can be root or the owner (normal
    >>> user).


    Correct.

    >>> this means a exploited program running as a normal user can dump an
    >>> executable in that directory, if the attacker puts common unix
    >>> executables in there


    Most users today are using 'sudo' rather than 'su' to execute
    "privileged" commands. How is your /etc/sudoers file configured? Does
    it grant unlimited access to everything as root, or is it limited?

    Note that this restriction does not apply to a person using 'su' to
    become root (lacking the '-' or '-l' retains the user's environment,
    which can be helpful if you've managed to fsck up root's environment).

    Also, the attacker has to be able to make a file executable before it's
    a problem. That limits attack possibilities, to some extent. If the
    attacker can actually muck with your dot-files, you are screwed just as
    badly as they can slip in an alias, or alter the PATH as they see fit.
    There is no bullet-proof configuration - it's only degrees of bullet
    resistance.

    >>> and if that dir is put in PATH like this PATH="~/bin:$PATH". then you
    >>> can be royally ****ed,


    Correct - which is why the PATH should never be modified in that manner.
    Note that this does not protect you if you are a klutz at typing, and
    make predictable errors such as typing 'ls-l'. I think that most of
    the Linux distributions I've been using over the years modified the
    users PATH in ~/.bash_profile to tack on the $HOME/bin at the end of
    the PATH.

    >>> this is especially true if your sudo is configured very
    >>> pragamatically eg the user is part of a group or can sudo anything
    >>> without PASSWORD eg: ALL=(ALL) NOPASSWD:ALL


    In that case, yes you are very properly screwed. But then, this is how
    you learn not to make stupid mistakes. Recall that the "." in the PATH
    problem occurred mainly in schools where the students shared access to a
    common directory, and it was writable by all members of a group. Giggle,
    giggle, giggle - look at that fool who just mistyped a command, and
    wiped his home directory. Ho, ho, ho. Students will be students.

    I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
    the stupidity of having "." in the PATH (Practical Unix & Internet
    Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
    edition - see page 113 for the box "Stealing Superuser").

    >damn it i forgot the attacker could simply sudo


    If the attacker knows you can sudo (or su) to root, they can use that
    knowledge to obtain the authentication token (if there is one), and
    then become root directly and screw the system without have to wait for
    you to trip over their malware.

    Old guy

  14. Re: Secure $PATH for regular user

    Moe Trin wrote:
    > On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    > <4727c4d7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:
    >
    >> goarilla wrote:

    >
    >>> goarilla wrote:

    >
    >>>> Moe Trin wrote:

    >
    >>>>> The dot (".") in the PATH (or ending the PATH with a colon ":" which
    >>>>> has the same effect) I can agree should not be in the PATH.

    >
    > I should point out that the ending colon trick is not a POSIX feature.
    >


    cool didn't know that

    >>>>> Most sane setups do not have that directory writable by other than
    >>>>> the owner, and placing nasties there requires the same elevated
    >>>>> permissions that are needed to replace system binaries in /bin/ or
    >>>>> permissions that are needed to replace system binaries in /bin/ or
    >>>>> similar. Hence, if they can screw up the users ~/bin, they can also
    >>>>> screw the entire system. What's the point?

    >
    >>>> huh system directories are owned and writeable only by root
    >>>> directories in the home directory are writeable by the user of that
    >>>> directory
    >>>> meaning: in case of system dirs the euid has to be root to dump
    >>>> malicious executables
    >>>> in case of the home dir, the euid can be root or the owner (normal
    >>>> user).

    >
    > Correct.
    >
    >>>> this means a exploited program running as a normal user can dump an
    >>>> executable in that directory, if the attacker puts common unix
    >>>> executables in there

    >
    > Most users today are using 'sudo' rather than 'su' to execute
    > "privileged" commands. How is your /etc/sudoers file configured? Does
    > it grant unlimited access to everything as root, or is it limited?
    >


    i only allow myself sudo access to the system tools i use most (about 12)
    which happens to contain iptables ( i love verbose statistics )
    and just plain playing around with it.

    some info:
    user@host:~ $ ls -l $(which su)
    -r-s--x--- 1 root wheel 31776 2006-08-22 22:08 /bin/su
    user@host:~ $ su
    root@host: $ sudo /bin/ls
    root is not in the sudoers file. This incident will be reported.

    i do (like to) think i keep it pretty spartan.

    > Note that this restriction does not apply to a person using 'su' to
    > become root (lacking the '-' or '-l' retains the user's environment,
    > which can be helpful if you've managed to fsck up root's environment).
    >
    > Also, the attacker has to be able to make a file executable before it's
    > a problem. That limits attack possibilities, to some extent. If the
    > attacker can actually muck with your dot-files, you are screwed just as
    > badly as they can slip in an alias, or alter the PATH as they see fit.
    > There is no bullet-proof configuration - it's only degrees of bullet
    > resistance.
    >
    >>>> and if that dir is put in PATH like this PATH="~/bin:$PATH". then you
    >>>> can be royally ****ed,

    >
    > Correct - which is why the PATH should never be modified in that manner.
    > Note that this does not protect you if you are a klutz at typing, and
    > make predictable errors such as typing 'ls-l'. I think that most of
    > the Linux distributions I've been using over the years modified the
    > users PATH in ~/.bash_profile to tack on the $HOME/bin at the end of
    > the PATH.
    >
    >>>> this is especially true if your sudo is configured very
    >>>> pragamatically eg the user is part of a group or can sudo anything
    >>>> without PASSWORD eg: ALL=(ALL) NOPASSWD:ALL

    >
    > In that case, yes you are very properly screwed. But then, this is how
    > you learn not to make stupid mistakes. Recall that the "." in the PATH
    > problem occurred mainly in schools where the students shared access to a
    > common directory, and it was writable by all members of a group. Giggle,
    > giggle, giggle - look at that fool who just mistyped a command, and
    > wiped his home directory. Ho, ho, ho. Students will be students.
    >
    > I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
    > the stupidity of having "." in the PATH (Practical Unix & Internet
    > Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
    > edition - see page 113 for the box "Stealing Superuser").
    >


    can you recommend that book ?
    looking for some paper that can scratch my itch (unix+security)

    >> damn it i forgot the attacker could simply sudo

    >
    > If the attacker knows you can sudo (or su) to root, they can use that
    > knowledge to obtain the authentication token (if there is one), and
    > then become root directly and screw the system without have to wait for
    > you to trip over their malware.
    >
    > Old guy


    still if this can mitigate even a small nr of attackers then it's a win

  15. Re: Secure $PATH for regular user

    On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <4727ffb7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:

    >Moe Trin wrote:


    >> I should point out that the ending colon trick is not a POSIX feature.


    >cool didn't know that


    You should verify this on your system however.

    >i only allow myself sudo access to the system tools i use most (about
    >12) which happens to contain iptables ( i love verbose statistics )
    >and just plain playing around with it.


    If your /etc/sudoers file lists the specific commands you are allowed
    use, then you are less vulnerable. Of course, if the attacker gets
    access to the system and can use sudo to edit the /etc/sudoers file,
    all bets are off. But as I said - it's a matter of degrees.

    >some info:
    >user@host:~ $ ls -l $(which su)
    >-r-s--x--- 1 root wheel 31776 2006-08-22 22:08 /bin/su
    >user@host:~ $ su
    >root@host: $ sudo /bin/ls
    >root is not in the sudoers file. This incident will be reported.


    PLEASE TELL ME THAT YOU EDITED OUT THE PASSWORD LINES.

    >> I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
    >> the stupidity of having "." in the PATH (Practical Unix & Internet
    >> Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
    >> edition - see page 113 for the box "Stealing Superuser").

    >
    >can you recommend that book ?
    >looking for some paper that can scratch my itch (unix+security)


    Eric S. Raymond hasn't been recommending the book in his 'Reading List
    HOWTO' since 2004 - feeling that it is dated, though the authors of the
    Security-HOWTO still list it.

    -rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO
    -rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO

    Personally, I do recommend the book, although it is expensive (list
    price US$55), but it's been around for a while so this also means you
    may find it in a public or university library. The first edition (1991)
    mainly covered UNIX security. It was completely re-written for the
    second edition (ISBN 1-56592-146-8, April 1996, 971 pgs) and material
    added about Internet security. The third edition (February 2003, 954
    pgs) has more practical information added.

    >> If the attacker knows you can sudo (or su) to root, they can use that
    >> knowledge to obtain the authentication token (if there is one), and
    >> then become root directly and screw the system without have to wait for
    >> you to trip over their malware.


    >still if this can mitigate even a small nr of attackers then it's a win


    It would be more useful if the administrators actually learned something
    about their systems in the first place. Many seem to want to install
    everything on the CD/DVD without making any effort to find out what it
    is, what it's used for, and whether or not it's going to be useful to
    them or merely another unpatched security hole. The distributions are
    partially to blame for this - playing the numbers game of "we have more
    stuff than the other guys". They try to make the systems somewhat
    self-maintaining (automatically checking for, and installing updates)
    but some block this function under the impression that the software is
    "calling home" with all kinds of secret/personal information.

    In many operating systems (and that even includes windoze), there may
    be unpatched security holes, but the FAR more common problem is user
    stupidity. Uncrackable computers are already available. It's uncrackable
    users that are in short supply

    Social Engineering - Because there's no patch for human stupidity.

    Old guy.

  16. Re: Secure $PATH for regular user

    Moe Trin wrote:
    > On Wed, 31 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
    > <4727ffb7$0$22317$ba620e4c@news.skynet.be>, goarilla wrote:
    >
    >> Moe Trin wrote:

    >
    >>> I should point out that the ending colon trick is not a POSIX feature.

    >
    >> cool didn't know that

    >
    > You should verify this on your system however.
    >
    >> i only allow myself sudo access to the system tools i use most (about
    >> 12) which happens to contain iptables ( i love verbose statistics )
    >> and just plain playing around with it.

    >
    > If your /etc/sudoers file lists the specific commands you are allowed
    > use, then you are less vulnerable. Of course, if the attacker gets
    > access to the system and can use sudo to edit the /etc/sudoers file,
    > all bets are off. But as I said - it's a matter of degrees.
    >
    >> some info:
    >> user@host:~ $ ls -l $(which su)
    >> -r-s--x--- 1 root wheel 31776 2006-08-22 22:08 /bin/su
    >> user@host:~ $ su
    >> root@host: $ sudo /bin/ls
    >> root is not in the sudoers file. This incident will be reported.

    >
    > PLEASE TELL ME THAT YOU EDITED OUT THE PASSWORD LINES.
    >


    Offcorse

    >>> I don't know if it was Gene Spafford or Simson Garfinkel who illustrated
    >>> the stupidity of having "." in the PATH (Practical Unix & Internet
    >>> Security, several editions, O'Reilly, ISBN 0-596-00323-4 for the third
    >>> edition - see page 113 for the box "Stealing Superuser").

    >> can you recommend that book ?
    >> looking for some paper that can scratch my itch (unix+security)

    >
    > Eric S. Raymond hasn't been recommending the book in his 'Reading List
    > HOWTO' since 2004 - feeling that it is dated, though the authors of the
    > Security-HOWTO still list it.
    >
    > -rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO
    > -rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
    >
    > Personally, I do recommend the book, although it is expensive (list
    > price US$55), but it's been around for a while so this also means you
    > may find it in a public or university library. The first edition (1991)
    > mainly covered UNIX security. It was completely re-written for the
    > second edition (ISBN 1-56592-146-8, April 1996, 971 pgs) and material
    > added about Internet security. The third edition (February 2003, 954
    > pgs) has more practical information added.
    >
    >>> If the attacker knows you can sudo (or su) to root, they can use that
    >>> knowledge to obtain the authentication token (if there is one), and
    >>> then become root directly and screw the system without have to wait for
    >>> you to trip over their malware.

    >


    what do you mean with authentication token ?

    >> still if this can mitigate even a small nr of attackers then it's a win

    >
    > It would be more useful if the administrators actually learned something
    > about their systems in the first place. Many seem to want to install
    > everything on the CD/DVD without making any effort to find out what it
    > is, what it's used for, and whether or not it's going to be useful to
    > them or merely another unpatched security hole. The distributions are
    > partially to blame for this - playing the numbers game of "we have more
    > stuff than the other guys". They try to make the systems somewhat
    > self-maintaining (automatically checking for, and installing updates)
    > but some block this function under the impression that the software is
    > "calling home" with all kinds of secret/personal information.
    >


    thats why i use slackware, freebsd

    > In many operating systems (and that even includes windoze), there may
    > be unpatched security holes, but the FAR more common problem is user
    > stupidity. Uncrackable computers are already available. It's uncrackable
    > users that are in short supply
    >


    talking about openvms, tandem ?

    > Social Engineering - Because there's no patch for human stupidity.
    >
    > Old guy.


  17. Re: Secure $PATH for regular user

    On Thu, 01 Nov 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <472913c7$0$22308$ba620e4c@news.skynet.be>, goarilla wrote:

    >Moe Trin wrote:


    >> goarilla wrote:


    >>> user@host:~ $ su
    >>> root@host: $ sudo /bin/ls
    >>> root is not in the sudoers file. This incident will be reported.

    >>
    >> PLEASE TELL ME THAT YOU EDITED OUT THE PASSWORD LINES.


    >Offcorse


    Hate to say how many people I've seen with a null password - even for
    the root account.

    >>>> If the attacker knows you can sudo (or su) to root, they can use
    >>>> that knowledge to obtain the authentication token (if there is
    >>>> one), and then become root directly and screw the system without
    >>>> have to wait for you to trip over their malware.

    >
    >what do you mean with authentication token ?


    What ever mechanism you are using to authenticate yourself. This could
    something as simple as a username and password - it's amazing how many
    people are still using telnet over the wire (which passes username and
    password en-clair for anyone to sniff), or someone installing a key
    sniffer on your system (or simply running the 'script' command to
    snarf all of your keystrokes). At the other extreme, this could be
    a one-time password or a token card system such as "SecureID" or
    "SecureNet". No matter what, the attacker merely has to be able
    to be able to learn your password by any means, and you get blamed
    for the attack.

    Some users also make it easy for the attacker, because they use a
    predictable username and password. In March 2003, there was a windoze
    worm called "deloader" that wreaked havoc with the windoze crowd by
    trying just 87 passwords for the "Administrator" account. Those 87
    included such difficult passwords as "" (which is to say 'nothing')
    "0", "1", or the really hard one "pass", and this cracked a large
    number of windoze boxes. I hate to tell you how often a password
    cracking tool such as "Jack the Ripper" has found such passwords on a
    *nix box.

    >> The distributions are partially to blame for this - playing the
    >> numbers game of "we have more stuff than the other guys". They try
    >> to make the systems somewhat self-maintaining (automatically
    >> checking for, and installing updates) but some block this function
    >> under the impression that the software is "calling home" with all
    >> kinds of secret/personal information.


    >thats why i use slackware, freebsd


    And on both of these, the first account the home or hobbyist user gets
    is... root. (It was six months before I learned who this 'root'
    was, and over a year before I got very limited extra privileges that
    allowed me to shut down the system, or mount/unmount tapes. I didn't
    get a root account for six MORE months after that.)

    A major problem is that the average computer user is not willing to
    learn what their computer is doing, and why. The distributions (and
    that includes the *BSDs) have to cater for this lower skill level.
    In April 1999, what was then 'Caldera Linux' introduced a brain dead
    installation program that allowed poorly trained monkeys to setup a
    Linux system from scratch. The other distributions had no choice but
    to emulate this. Sure, there are more users of Linux (and *BSD)
    today, but where are their skills? Just click that icon, and all
    will be well.

    >> In many operating systems (and that even includes windoze), there may
    >> be unpatched security holes, but the FAR more common problem is user
    >> stupidity. Uncrackable computers are already available. It's uncrackable
    >> users that are in short supply

    >
    >talking about openvms, tandem ?


    Actually, any of the 'secure' or 'trusted' distributions of Linux will
    do - as will OpenBSD. There are also trusted (but because they are not
    certified, can't be called) UNIX out there as well. Generally, these
    put more barriers in place, such as access control lists, or the NSA
    SELinux hooks. Out of box, they can be _practically_ uncrackable. But
    then you add users...

    >> Social Engineering - Because there's no patch for human stupidity.


    Old guy.

  18. Re: Secure $PATH for regular user

    On 30 Oct, 18:00, Chris Cox wrote:
    > On Tue, 2007-10-30 at 06:17 -0700, Nico wrote:
    > > On 29 Oct, 10:37, Dmitry wrote:
    > > > Hi,

    >
    > > > I remember, but can not find it, that for non root user it's advised
    > > > not include /sbin and /usr/sbin in $PATH. Is it right?

    >
    > > > If yes, I'll be glad to find a reference to security audit indicating
    > > > it, as a proof to my manager

    >
    > > Under most Linux systems I've seen, there's a widget in /etc/profile
    > > that *provides* /sbin and /usr/sbin for the root user, and does not do
    > > so for non-root users. This is irritating if you use sudo to run
    > > things as root, since programs from the sbin directories are not in
    > > the PATH as expected.

    >
    > The correct answer for those cases is to use the -i option (on newe
    > versions of sudo). The security risk is with sudo since it does leave
    > the PATH alone, which is exactly the huge security risk mentioned in my
    > other post in this thread. Again, has nothing to do with the what the
    > OP was asking...
    >
    >
    >
    > > Now, the "." and the "~/bin" directories, *those* do not belong in the
    > > default PATH.

    >
    > But sudo inherits the PATH of the current user invoking sudo. This is
    > VERY dangerous. Something to remember. e.g. Let's say your PATH is
    > PATH=/myuglynasty/bin:$PATH and inside that myuglynasty/bin directory
    > has fairly open permissions and a vicious copy of a common executable.
    > Hopefully you can see the problem.


    No, because default users in these Linux systems do not get /usr/sbin
    or /sbin in their path! It's filtered out in the /etc/profile, so you
    do not in fact get the default PATH for the root user because neither
    the "sudo -H" nor the "sudi -i" re-source the /etc/profile file where /
    sbin and /usr/sbin get added, when your UID is 0 as for the root user.


  19. Re: Secure $PATH for regular user

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    ,--- Dmitry writes:
    | Hi,

    | I remember, but can not find it, that for non root user it's advised
    | not include /sbin and /usr/sbin in $PATH. Is it right?

    I'm also not sure about thether it is some kind of recommendation, but
    authentication mechanisms of couple of Linux distros (at least Redhat
    based) relies on this assumption.

    - ----8<----8<----
    wahjava [~] chatteau $ ls -l /usr/bin/system-config-network
    lrwxrwxrwx 1 root root 13 2007-09-10 12:31 /usr/bin/system-config-network -> consolehelper
    wahjava [~] chatteau $ ls -l /usr/sbin/system-config-network
    - -rwxr-xr-x 1 root root 188 2007-09-06 13:35 /usr/sbin/system-config-network
    - ---->8---->8-----

    e.g. in above case when unprivileged user executes
    'system-config-network' (with no /sbin:/usr/sbin in PATH),
    '/usr/bin/consolehelper' gets started and does the authentication work
    and if user is authenticated successfully, starts the actual
    executable, which in above case present in '/usr/sbin'. So in such

    | If yes, I'll be glad to find a reference to security audit indicating
    | it, as a proof to my manager

    | Thanks
    | Dmitry

    HTH
    - --
    Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
    ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHM2utHy+EEHYuXnQRArwsAJ40l6UjRtoSrJo23le+F6 iWGzCWbACeN+Jk
    W0RWzWU5W9DQH2vJYjAJa6Y=
    =nOBI
    -----END PGP SIGNATURE-----

  20. Re: Secure $PATH for regular user

    On Fri, 09 Nov 2007, in the Usenet newsgroup comp.os.linux.security, in article
    , Ashish Shukla
    =?utf-8?B?4KSG4KS24KWA4KS3IOCktg==?= =?utf-8?B?4KWB4KSV4KWN4KSy?= wrote:

    >--- Dmitry writes:


    >| I remember, but can not find it, that for non root user it's advised
    >| not include /sbin and /usr/sbin in $PATH. Is it right?
    >
    >I'm also not sure about thether it is some kind of recommendation, but
    >authentication mechanisms of couple of Linux distros (at least Redhat
    >based) relies on this assumption.


    I certainly would not call that 'authentication'.

    > ----8<----8<----
    >wahjava [~] chatteau $ ls -l /usr/bin/system-config-network
    >lrwxrwxrwx 1 root root 13 2007-09-10 12:31 /usr/bin/system-config-network

    -> consolehelper
    >wahjava [~] chatteau $ ls -l /usr/sbin/system-config-network
    >-rwxr-xr-x 1 root root 188 2007-09-06 13:35 /usr/sbin/system-config-network
    >---->8---->8-----
    >
    >e.g. in above case when unprivileged user executes
    >'system-config-network' (with no /sbin:/usr/sbin in PATH),
    >'/usr/bin/consolehelper' gets started and does the authentication work
    >and if user is authenticated successfully, starts the actual
    >executable, which in above case present in '/usr/sbin'. So in such


    ....? Have no idea what you were going to say there.

    You might have a look at the PATH for the user, and for root. You will
    see that root has the same basic directories in his PATH, but that
    the 'sbin' directories come before the 'bin' directories. Otherwise,
    the so-called "consolehelper" application would be hit by root trying
    to use the other so-called helper programs like 'system-config-*'.
    Recall that the shell will use (excluding built-ins) the first
    usable instance of a command found in the PATH. 'consolehelper'
    was developed to allow more limited access to privileged commands
    by ordinary users in an effort to reduce the number of newbies
    using the privileged account for ordinary use as they do in windoze
    because they feel they need the extra privilege for some reason.

    The 'system-config-*' (originally called 'redhat-config-*' and renamed
    in Fedora Core 2) are replacements for the earlier (RH5.1) 'linuxconf'
    helper that Red Hat selected as the tool to help inexperienced system
    administrators. These helpers tend to be proprietary, and limited to
    a distribution (and it's clones if any). Other distributions use other
    tools - 'sudo' being yet another mechanism, and even the GUI desktops
    are getting into the act with their own "tools". Another disadvantage
    of these helpers is that they tend to hide what they are actually doing,
    and when the tool is missing, or won't work, the inexperienced admin
    is left without recourse.

    Old guy

+ Reply to Thread