Re: Veritas Volume Manager 3.0.x hole

[doug () ENG AUBURN EDU (Doug Hughes)]

On Fri, 16 Jun 2000, Dixie Flatline wrote:
> Workaround & Comments
> ---------------------
>
> The trivial workaround: add "umask 022" to /etc/rc2.d/S96vmsa-server
> before the line that starts the Storage Administrator Server.

Don't edit the file. It'd just be changed on the next upgrade, or possibly
even the next patch. It's much better to add a new file in rcS.d, rc2.d,
and rc3.d called S00umask.sh (one in each dir - or link it)
in the files put:
umask 022
It's good innoculation against spurious /tmp files, and it has been
recommended practice for many years.

> Perhaps a better fix would be to change Storage Administrator to only
> write process ID numbers to /var/opt/vmsa/logs/.server_pids, and change
> the control script to extract only those PIDs from the file, instead of
> executing the contents. This would still require that permissions on that
> file be sane in order to avoid some level of compromise (otherwise, an
> unprivileged user could kill arbitrary processes). A better approach would
> be to use a utility like pkill(1) to find and kill the appropriate
> processes (a functional equivalent could easily be coded into
> vmsa_server).
>
> I found no previous mention of this hole on SunSolve, (sunsolve.sun.com),
> SecurityFocus (www.securityfocus.com), PacketStorm Security
> (packetstorm.securify.com), the Veritas web site, the main Sun web site, or in
> the archives of the Bugtraq mailing list. My apologies if this is old
> news.
>
> Please send comments to echo8 () gh0st net.

There is some mention of S00umask.sh, but it's not obvious..
____________________________________________________________________________
Doug Hughes                                     Engineering Network Services
System/Net Admin                                Auburn University
                        doug () eng auburn edu