Re: sa-compile will not configure
No I don't. I have not used Gentoo and am not on that mailing list.. I hope my questions do not appear too newbie, since I've been running Unix systems for a long time, although this particular one had me stumped. Thelma is the name of one of my servers, another is Louise. That location has servers with all female names our other location has all male names. Ian Zimmerman wrote: On 2017-04-20 17:31, Robert Steinmetz AIA wrote: thelma@thelma:~$ echo $PATH BTW, do you have any connection to the Thelma who's asking a constant stream of close-to-newbie questions in the Gentoo user mailing list? It's not that common a name, so forgive me for the short-circuit in my brain :-) -- Robert Steinmetz AIA Principal Steinmetz & Associates New Orleans & Atlanta
Re: sa-compile will not configure
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
Re: sa-compile will not configure
Reindl Harald wrote:
just ask your distribution how they broke your environment
this is *not* a spamassassin issue and all the stuuf you do abvoe
is not supposed to make things better - how do you imagine "I
deleted the /usr/bin/X11 link and created a new directory
/usr/bin/X11 but it still failed" has any relation to
spamassassin?
While not a direct Spamassassin issue Sapmassassin is the only
package this problem affects, every other package configures
properly.. It is ultimately a perl issue, but as Bill Cole helpfully
wrote:
The sa-compile script DOES use a SA utility
function to untaint the whole %ENV hash, but there's a special
catch for $ENV{'PATH'}: if any directories included are not
absolute (e.g. commonly '.' and '~/bin') OR are writable by more
than their owning user & group, $ENV{'PATH'} remains tainted
and won't be used or passed to child processes. Often a bad
member directory is unobvious because it is a symlink name and
symlinks are usually technically mode 777 because the system
doesn't use the mode of a symlink itself.
I was checking to see if all of the directories in $PATH were OK.. I
posted the entire results of those tests to allow someone more
knowledgeable than I am about Spamassassin and perl to see if there
was another problem.
The reason for deleting and reinstalling /usr/bin/X!1 was to test
is a Bill Cole's suggestion that a symbolic link might be the cause
of the issue, I think I've shown it's not.
Which links back to specific Spamassassin code. Determining why that
code is not functioning correctly is the route to solving the whole
problem. If it turns out the Spamassassin code its to blame then it
is a Spamassassin issue.
Re: sa-compile will not configure
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
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
thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin
thelma@thelma:~$ ls -ld /bin
drwxrwxrwx 3 root root 4352 Apr 15 19:06 /bin
ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11 2007 /usr/bin/X11 -> .
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
thelma@thelma:/usr/bin$ ls -ld /snap/bin
drwxr-xr-x 2 root root 48 Apr 20 15:55 /snap/bin
I was little concerned about what to do with /usr/bin/X11
I deleted the /usr/bin/X11 link and created a new directory /usr/bin/X11
but it still failed.
I deleted the directory and remade the link.
I'd also prefer not to modify sa-compile since the next time there is a
update it will likely be overwritten.
Hopefully someone can shed a clue
Bill Cole wrote:
Inside a perl script, the execution environment is available in the
%ENV hash, with variable names as keys, so the execution search path
"PATH" is "$ENV{'PATH'}". The %ENV hash is considered "tainted" as
untrustworthy input by perl, so if the interpreter is run with the
"-T" option, any subprocess launched by perl won't get any environment
variables unless the script has done something to "untaint" members of
that hash. The sa-compile script DOES use a SA utility function to
untaint the whole %ENV hash, but there's a special catch for
$ENV{'PATH'}: if any directories included are not absolute (e.g.
commonly '.' and '~/bin') OR are writable by more than their owning
user & group, $ENV{'PATH'} remains tainted and won't be used or passed
to child processes. Often a bad member directory is unobvious because
it is a symlink name and symlinks are usually technically mode 777
because the system doesn't use the mode of a symlink itself.
What I expect is happening is that there's a problematic directory in
the $PATH that perl gets when executed, so the blind untainting of
$ENV{'PATH'} that sa-compile does won't work. The best fix is to find
the insecure member of $PATH and remove it before trying to run
sa-compile.
