Thank you Bill,
I checked all of the permissions at every level, they were all 755
except for as noted, which I changed. to 755
It works now.
I'll re-check this in the morning and run security scans to make sure
everything is tied down..
I appreciate your help.
Bill Cole wrote:
On 20 Apr 2017, at 16:16, Robert Steinmetz AIA wrote:
Thank you Bill,
That has given me a clue. I ran the commands below:
thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin
thelma@thelma:~$ ls -ld /usr/local/sbin
drwxr-xr-x 2 root root 48 Mar 11 2007 /usr/local/sbin
thelma@thelma:~$ ls -ld /usr/local/bin
drwxr-xr-x 2 root root 48 Mar 11 2007 /usr/local/bin
OK, it MAY be that perl is also looking up the tree. If /usr/local is
world-writable, then these 2 effectively are also (since they could be
renamed and replaced with evil twins.)
thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin
thelma@thelma:~$ ls -ld /usr/bin
drwxr-xr-x 4 root root 72872 Apr 18 16:44 /usr/bin
The above note about /usr/local also applies to /usr
thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin
I think you meant /sbin here.
thelma@thelma:~$ ls -ld /bin
drwxrwxrwx 3 root root 4352 Apr 15 19:06 /bin
That's a problem. Enough of a problem that if this system has any
other users who could have logged in OR any remote-accessible services
that might be attack paths, you should reload from bare metal. Having
/bin (or /sbin, /usr/bin, or /usr/sbin) world-writable essentially
hands over control to anyone who knows about the flaw, wants the
machine, and has some way to get in.
I have no idea how /bin could have become world-writable short of
administrative malpractice or a prior malicious system compromise.
ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11 2007 /usr/bin/X11 -> .
That's a weird Ubuntu (or Debian?) quirk. It shouldn't be necessary
but it probably shouldn't be fiddled with either, except maybe to
'chmod -h o-w /usr/bin/X11' (to remove the world-writable permission
from the symlink.)
ls -ld /usr/games
drwxr-xr-x 2 root root 784 Apr 15 18:17 /usr/games
ls -ld /usr/local/games
drwxr-xr-x 2 root root 48 Mar 11 2007 /usr/local/games
ls -ld /snap/bin
ls: cannot access '/snap/bin': No such file or directory
Note that /snap/bin doesn't exist and /usr/bin/X11 links to "."
I added /snap/bin as an empty directory but it still fails
I've not seen that in a default $PATH. Is it something you use
locally? Here again, the permissions of directories up to the root MAY
be taken into account by perl for untainting purposes, I'm not sure.
There's no sound reason for /, /usr, or any directory whose contents
you care about to be world-writable without the "sticky" bit set (as
with /tmp and /var/tmp) so you could safely do this:
chmod -h o-w $( echo $PATH | tr ':' ' ' )
--
Rob
