Keeping clients out of some file systems
ronald at kuetemeier.com
Tue May 15 00:09:24 GMT 2001
I have implemented file-system/dir blocking. The dir will only be
blocked if they are referenced from a share by a link.
[ blocked ]
mount_point = /proc
mount_point = /
mount_point = /usr
dir_name = /usr/local/src/samba
END conf file;
DIRs and links:
DIR a: /usr/local/src/linux
DIR b: /usr/local/src/samba
LINK on SHARE [home] c: [/home/ronald]local->/usr/local
LINK on SHARE [home] d: [/home/ronald]samba->/usr/local/samba
Then everything on file-system /proc,/, and /usr is not accessible via
a link from a share, also /usr/local/src/samba is not accessible from
a link on a share.
For example the dir /usr/local/src/linux (a) is accessible from link c, but
/usr/local/src/samba (b) is not accessible from link c. That (b) is blocked
from link d should be self explaining.
ALso if you share /usr/local/ all is up to normal permission checking.
Attached source, as usual 2.2.0 --with-vfs is needed.
> On Sat, May 12, 2001 at 10:26:19AM +0900, okuyamak at dd.iij4u.or.jp wrote:
>>>>>>>"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,
>> /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.
>> Part 1.1
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3303 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20010514/8665c0fb/vfs-block.obj
More information about the samba-technical