YASSP

Known problems, FAQ

DRAFT: This page *IS* being written. Any suggestion is welcome!

• Can I install YASSP or SECclean on an existing server?

  You can try! :-)
  SECclean try to be very careful when it touch some existing files. SECclean installation will tell you which file were modified and were the original was saved. You may need to re-edit some configuration files and re-apply some setting. I can say a firm yes as I don't want to be responsible for some disater :-) but in the worst case, de-installing it should put you back in order.
  Note: Yassp or SECclean will change the Solaris setting. It won't be aware of any additional configuration files or startup file. It is up to the administrator to verify any additional software. Any additional startup script will *not* be controlled by /etc/yassp.conf

• 'boot -r' does not reconfigure the devices anymore.
• Hot-pluggable devices doesn't work any more0 .
• Will YASSP run on Solaris 2.X, where X != [678].

  The tarball will refuse to install. If you try the manual installation, SECclean will failed to install the right /etc/init.d/inet[svc|inet] init file as it won't have the one corresponding to your OS.
  Solaris 8 is supported since Beta-final#6.

• After installing YASSP (or SECclean) I can't log anymore to the workstation from the network.
  • By default, SECclean modify /etc/init.d/inetsvc not to run inetd at all. Edit /etc/yassp.conf and set RUNINETD to YES.
  • SECclean has commented out all the line of /etc/inetd.conf. Edit it and un-comment the services you want to run.
  • If you have installed ssh, and if TCP-wrapper is part of the package installed by yassp (Default choice), you need to modify /etc/host.allow and/or /etc/host.deny to allow ssh connection from where you want.
• Netscape products do not work anymore.

  Some people reported problems running Netscape server or communicator after installing YASSP. It looks like Netscape products need nscd to work properly. Edit /etc/rc.conf and set NETSCAPE to 'YES'.

• Some services like DTlogin or NFS do not run anymore.

  SECclean turn off most of the services by default. Edit /etc/rc.conf and re-enable what you need.

• Some applications do not run correctly anymore.

  Hard to say what is wrong, but here is two good starting points:

  • May be the application rely on a network services which is turn off by YASSP.
  • Check your logs to see if their is a stack-smashing attacks logged. If yes, edit /etc/system an, comment out the line set noexec_user_stack=1 reboot and try again. Beware that stack-smashing attacks will be possible.
• I ran YASSP but now every time I add a new filesystem mount, I am unable to successfully execute the command `pwd' when my current working directory is under that mount point, or the command `ls -la' on the mount point itself. What gives?

  YASSP changes the system-wide umask set in /etc/profile to 077 by default . This means that new directories are created with permissions of 0700, rather than the 0755 that would be the case for most non-YASSP systems. If a directory `/foo' is created with these permissions, and is then used to mount a filesystem whose top-level directory has less restrictive permissions, such as 0755, then `/foo' will appear to have those less restrictive permissions:

  # ls -ld /foo
  /foo: No such file or directory
  # umask 077
  # mkdir /foo
  # ls -ld /foo
  drwx------ 3 root other 512 Aug 22 09:19 /foo
  # mount /dev/dsk/c1t0d0s1 /foo
  # ls -ld /foo
  drwxr-xr-x 3 root other 512 Jul 24 11:16 /foo

  Since a filesystem cannot know beforehand where it will be mounted, it can't know what the permissions on the parent directory of its mount point will be, and thus the entry for `..' in the top-level directory of a filesystem is meaningless. Thus, when an attempt is made to access `/foo/..' (for example, via a pwd), the OS actually does a stat of the `..' entry in the directory `/foo' under the root filesystem, rather than the `..' entry in the top-level directory of the mounted filesystem stored on /dev/dsk/c1t0d0s1 (or whatever the device is). Since the permissions on that hidden mount point do not allow access to users other than the root user, the stat will fail:

  $ ls -l /foo/..
  /foo/..: Permission denied
  $ cd /foo
  $ pwd
  pwd: Permission denied
  $ sudo pwd /foo

  YASSP has thus not broken anything; instead, this is the correct behaviour (on all UNIX-like OSes other than Linux) for a somewhat pathological situation that YASSP makes more common.
  Fix: The proper workaround is to unmount the filesystem, change the permissions on the mount point to match those of the filesystem's top-level directory, and remount the filesystem.