Keeping clients out of some file systems

[okuyamak at dd.iij4u.or.jp]

Dear Michael,

>>>>> "MG" == Michael Gerdts <Michael.Gerdts at usa.alcatel.com> writes:
MG> Typically to keep clients out of file systems that they should not be
MG> poking around on (/ /usr, /var, ...) you have to use "wide links = no",
MG> which apparently has performance problems.

MG> Generally, I don't care if people have symbolic links that point out of
MG> their shares, so long as they don't give away information that they can't
MG> already get through NFS.  That is, if Alice has a symbolic link to Bob's
MG> home directory, I don't care.  If Alice has a symbolic link to /, I care.

MG> Perhaps a new option, "hide filesystems" would be useful.

MG> 	hide file systems = / /opt /usr/local


Beside performance, we sometime needs to share some partial directories.

For example, we might need to hide /home except for /home/<that
user>, and /home/share.

Maybe we need 'jail' support too.


By the way, followings are the directories I think we should not
share with Samba, nor have example about it. Any opinion?

* Directories that subdirectories might need to share, but should
  not share itself:

/, /var, /home, 


* Directories that subdirectories also should not be shared:

/etc, /bin, /lib, /sbin, /usr/sbin, /usr/bin, /usr/lib, /usr/share,
/usr/local/bin, /usr/local/share, /usr/local/lib, /usr/local/sbin,
/usr/X11*,
 /var/* except for /var/spool in case of printing,
/usr/local/samba ( or any other place where samba and it's setting exists ),
/opt /usr/lpp and other 'OS dependent' directories for binaries.


# rules so far:
# 1) we should not share directories which can lead to anywhere.
# 2) we should not share binaries ( which never runs on Windows )
#    nor libraries
# 3) we should not share any setting files about the server.
# 4) we should not share any log, etc. which gives cracker extra hint
#    about the server
# 5) we should not, among all, share samba directories which we might
#    give tremendeus hints of cracking.
---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.