Keeping clients out of some file systems

[Ronald Kuetemeier]

I have implemented file-system/dir blocking. The dir will only be
blocked if they are referenced from a share by a link.
For example:

CONF FILE:
[ 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.
Ronald

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:
> 
>>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.
>>
>> Part 1.1
>>
>> Content-Type:
>>
>> text/plain
>>
>>
>> ------------------------------------------------------------------------
>> vfs-block.tgz
>>
>> Content-Type:
>>
>> application/x-tar-gz
>> Content-Encoding:
>>
>> base64
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfs-block.tgz
Type: application/octet-stream
Size: 3303 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20010514/8665c0fb/vfs-block.obj