[Samba] Wide links and insecure wide links

[Stilez Stilezy]

I checked out the Samba wiki. It looks like the source for the docs is in
the git repo, mirrored on Github. I'm more familiar with Github than CLI
git. Unless someone suggests otherwise, I'll try to add a small PR to the
docs xml pages there, which seem to be the original source for man pages
and get mirrored to the main repo.

Following on from this, I notice that the params used to control symlinks
feel a bit inefficient and inelegant, and quite limited/restrictive.  I
think there might be a good opportunity to simplify and also make symlink
management more powerful and adaptable to use-cases.  I'm guessing this
list is a good enough starting point to propose a smb.conf param change to
this area and see what reactions it gets. I'll put this in a separate
thread for clarity as the original question has been addressed.

Thanks for the help,

Stilez


On 28 February 2018 at 20:41, Jeremy Allison <jra at samba.org> wrote:


> On Wed, Feb 28, 2018 at 08:36:14PM +0000, Stilez wrote:
> > Thank you.
> >
> > So, If I understand correctly, "ordinary" "wide links = yes", means Samba
> > *will* traverse an existing symlink that points outside the root of the
> > share, if permissions allow. However because it *also* disables SMB1 Unix
> > extensions, it *also* prevents the user from creating or modifying
> symlinks
> > on the share, so in wffect it inherently prevents this being exploited
> > unless an insecure symlink already exists or is created by some *other*
> > route. And thus, that enabling "insecure" wide links simply  removes that
> > safeguard.
>
> Yes.
>
> > If that's right, my clarification questions are
> >
> > 1) does this mean that configs containing "ordinary" wide link = yes
> might
> > become a risk, when SMB2 style functionality eventually lands, or will it
> > presumably be mitigated or remain unchanged from a security perspective
> at
> > that time, as far as is known?
>
> My plan for SMB2 unix extensions is to prevent a client from
> creating *any* server-followed symlinks. So wide links = yes
> will remain the same as it is now, in that it will allow existing
> links to be followed outside the share path, but no new ones
> created. If you have existing wide links that point to /etc/passwd
> etc. then you're already unsafe. If you don't, then you're
> safe.
>
> > 2) when you say in your reply, that "ordinary" wide links enabled  "means
> > the server will follow symlinks **on the file system*" that point outside
> > the root of the share definition", do you in fact mean that it is also
> > barred from crossing a device boundary onto another device (similar to
> > "ls|rm|find -x", using stat to determine same file system), or something
> > else (in which case what?)
>
> No, it's nothing to do with underlying filesystem boundaries.
> What it means is that for a share definition of:
>
> path = /foo/bar
>
> that any link pointing to a file object that does *not* start
> with /foo/bar is disallowed by the server if "wide links = no",
> (e.g. /tmp or /foo/bibble) and all link paths are allowed if
> "wide links = yes".
>
> > Thanks for the help!
> >
> > Last thing - how can this helpful info added to smb.conf doc/man pages
> where
> > it might help others?
>
> Add to the Samba wiki ?
>
>