On Mon, 29 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article <1193654274.587361.265790@v3g2000hsg.googlegroups.com>, 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.

On 2007-10-30, Nico <nkadel@gmail.com> wrote: > > Now, the "." and the "~/bin" directories, *those* do not belong in the > default PATH. > I can understand "." but why "~/bin"?

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 :D) >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 :D 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.

On Fri, 09 Nov 2007, in the Usenet newsgroup comp.os.linux.security, in article <m34pfw7bdf.fsf@chatteau.d.lf>, 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