samba - Feb 2018 - Wide links and insecure wide links

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.

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?

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?)

Thanks for the help!

Last thing - how can this helpful info added to smb.conf doc/man pages 
where it might help others?

Stilez



On 28 February 2018 19:48:37 Jeremy Allison <jra at samba.org> wrote:
> On Wed, Feb 28, 2018 at 07:30:45PM +0000, Stilez wrote:
>> Thanks - that much I (pretty much) got.
>>
>> Its really the "wide links" option that isn't well
distinguished/clarified.
>>
>> *insecure* wide links is much more clear, although the detail
you've given
>> helps a lot.
>>
>> What exactly is the "ordinary" "wide links = yes"
option going to do (with
>> or without Unix extensions), and how does it compare/how much exposure
to
>> mischief does it expose?
>
> "ordinary" "wide links = yes" means the
> server will follow symlinks on the file
> system that point outside the root of the
> share definition. If set to off (default),
> the server will refuse to follow symlinks
> that point outside of the root of the
> share definition, but will follow symlinks
> that point within the share.
>
> If this is turned on, it disables SMB1
> unix extensions (which allow symlinks
> to be created by the client) unless
> "insecure wide links" is *also* turned
> on.

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 ?

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 ?
>
>