[PATCH] s3: introduce new share parameter "open special files"

[Volker Lendecke]

On Sat, May 04, 2013 at 11:47:25AM -0400, Simo wrote:
> On 05/04/2013 04:12 AM, Volker Lendecke wrote:
> >On Sat, May 04, 2013 at 08:11:59AM +1200, Andrew Bartlett wrote:
> >>On Fri, 2013-05-03 at 13:31 +0200, Ralph Wuerthner wrote:
> >>>On Fri, 3 May 2013 13:15:33 +0200
> >>>Ralph Wuerthner <ralphw at de.ibm.com> wrote:
> >>>
> >>>>Hi list,
> >>>>
> >>>>attached patch introduces a new share parameter "open special files"
> >>>>to control whether special files such as sockets, devices and fifo's
> >>>>will be opened by the server or not. If set to "no" open requests to
> >>>>special files will fail with "access denied". Default value for "open
> >>>>special files" is "no".
> >>>>
> >>>>Access to special files impose a security risk because it may for
> >>>>example allow remote clients raw access to local hard drives or
> >>>>kernel memory.
> >>>>
> >>>>Regards
> >>>>
> >>>>	Ralph
> >>>I found a bug in above patch: the check for special files
> >>>must be done after checking for directories. Otherwise opening a
> >>>directory as a file will fail with "access denied" instead of "file is
> >>>a directory".
> >>So, does this pass a full 'make test' now?
> >>
> >>I'm quite sceptical about this patch - special files come in many types
> >>- fifos that can and are used by folks for communication between clients
> >>and server processes, and character devices that could plausibly be used
> >>in the same way, and block devices/socket that are unlikely to make
> >>sense remotely.
> >>
> >>Why set this to 'no' by default?  Remote access to kernel memory or
> >>local hard drives would mean that either the remote user is root, or any
> >>local user (or local process) on the system already has such access.
> >>
> >>Having Samba be the 'last line of defence' in this situation seems
> >>wrong.  If these can somehow be created unsafely (backups of remote
> >>sytstems for example), why not mount with 'nodev' and have the kernel
> >>enforce this for everyone, and for all remote file servers, such as
> >>http, afp and ftp?
> >The use case is shared file systems between NFS / for
> >diskless workstations and cifs. It's exactly the same
> >argument we had with unix extensions and wide links. For
> >NFS, device nodes are opened on the client side (symlinks
> >are followed client-side), for Samba both are evaluated
> >server-side. Those two concepts just don't match. In the
> >discussion with wide links we opted to default on the safe
> >side, disabling simultaneous unix extensions and wide links.
> >I would argue that the same principle could be applied here.
> 
> This argument make sense, but if that's the case I would simply just
> extend the wide links option semantics and return the device node to
> a posix extensions enabled client so that it behaves like nfs and
> deny to non posix extensions enabled one.

Ok, then we have to look at what cifs.ko does. Does it go
through the full ntcreate/open code for this, or is a
stat-like call sufficient for it? Ralph, can you try that
with a recent Linux kernel client and unix extensions
enabled?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de