[Samba] widelinks_warning - but unix extensions *are* off

[L.P.H. van Belle]

Thanks you, an email to save, good info. 
I didnt know about the : proc/sys/fs/protected_hardlinks   

Thanks ! 

Louis
> -----Oorspronkelijk bericht-----
> Van: Linda W [mailto:samba at tlinx.org]
> Verzonden: zondag 8 november 2015 0:18
> Aan: thomas.werschlein at geo.uzh.ch
> CC: L.P.H. van Belle; samba at lists.samba.org
> Onderwerp: Re: widelinks_warning - but unix extensions *are* off
> 
> L.P.H. van Belle wrote:
> >  # G = Global, S = Share
> >  unix extensions (G)
> >  allow insecure wide links (G)
> >  wide links (S)
> >  follow symlinks (S)
> >
> >  If is not recommended to enable this option unless you fully
> >  understand the implications of allowing the server to follow
> >  symbolic links created by UNIX clients. For most normal[sic] Samba
> >  configurations this would be considered a security hole and setting
> >  this parameter is not recommended.
> >
> >  This option was added at the request of sites who had deliberately
> >  set Samba up in this way and needed to continue supporting this
> >  functionality without having to patch the Samba code.
> ---
> 
>     Depends on whether you come from a linux/unix background vs.
> a windows background.  Windows setups tend not to allow users to login
> to the server because windows has been too vulnerable to privilege
> escalation in the past.
> 
>     The same _may_ be true on unix systems, but in the unix
> environments I've worked in, the unix users in a given "domain" (like
> "Eng[ineering]"), were considered to be trusted and responsible users
> that did have and were given access to Servers in the "Eng" domain.
> "If they were not trusted and responsible, then why would the company
> hire them?", i.e. why would the company have then as employees?
> 
>     Given the defaults, above, there is no such thing as an "insecure
> wide link".  Since All the users in a domain could already login to
> the server and create links wherever the unix-permissions (UID/GID)
> allowed -- and, as symlinks -- they could point anywhere -- including
> /dev/null or /../nowhere.  I.e. symlinks were never trusted the way
> "hard links" were trusted.
> 
>     Similarly, hardlinks to protected files were not a problem, since
> you can't create hardlinks in any directory you didn't have write and
> execute access to (and read in some cases).  At the same time, you
> can't change access bits on a hard-linked file unless you were already
> the owner.  So creating a hardlink to /etc/passwd didn't give you any
> rights you didn't already have with /etc/passwd.
> 
>     Making the above secure also involved other good practices like
> keeping user-writable partitions separate from OS partitions (and
> maybe separate from daemon-writable partitions).  As well assigning
> a separate GID to each UID, and having a security system that allows
> GID-nesting just as one can add multiple UID's to a group.  Systems
> like Win-domains+AD's, and NIS/YP both allow such nesting.
> 
>     So people coming from a trusted-employee background that had these
> features saw no problem with "unix-extensions" co-existing with
> "widelinks" as the security models in which they existed made
> things *more* secure than many of the workarounds and, especially, the
> associated *mindsets* (i.e. defaulting to hiring non-trust-worthy
> employees; note: "eng" domain users still were walled off from "legal"
> or "corporate" domains as the *types* of information each domain dealt
> with were of different sensitivity levels (cf. Chinese-Wall security
> setups).
> 
>     Samba became a mixing round of employees coming from both types of
> backgrounds -- the trusting type, and the Win-type where every
> privilege or restriction usage/violation was an auditable event and
> privileges to even edit your own desktop are finely grained and
> controlled.
> 
>     That was very different from the default "trusted eng-devel
> background", make this issue a hot spot where the
> trusted-background/chinese-wall type security setups were mostly
> forgotten about and categorically labeled "insecure" ("allow insecure
> wide links" used to be called "allow client managed wide links" --
> saying exactly what they did rather than some blind "insecure" label).
> 
>     Anyway, to address the problem you run into, have your share's use
> "includes".  At the global level have the global option needed:
> 
>     allow insecure wide links = yes (G)
> #    unix extentions = yes (default)
> 
> ---
> Then have multiple "share-include files":
> 
> >  ls *share*.inc
> ro_share.inc        shares+recyl+shadcop.inc
> shares+recycle.inc  shares_basic.inc
> 
> >  egrep 'include|share|wide' *.inc
> 
> ro_share.inc:             wide links      = yes
> 
> shares_basic.inc:         wide links      = yes
> shares_basic.inc:#        follow symlinks = yes (default)
> 
> shares+recycle.inc:       include  = /etc/samba/inc/shares_basic.inc
> shares+recyl+shadcop.inc: include  = /etc/samba/inc/shares_basic.inc
> 
> 
> Note, wide-links are enabled in the basic and read-only
> shares and other share-types include one of those.
> Also in the ".inc" files are options I wanted to be
> common to those shares like block-size, acl-inherit,
> vfs objects...etc.
> 
> Note, that the normal practices that supported the above
> security, like separating partitions -- is going in the
> opposite extreme where people are converting distro's to
> support "appliance" or "console" type applications where
> everything is on 1 partition.
> 
> To support the lack of secure defaults that supported
> schemes like the above, linux has added 2 new options
> that are relevant to these setups:
> 
> >  ls /proc/sys/fs/*link*
> /proc/sys/fs/protected_hardlinks  /proc/sys/fs/protected_symlinks
> ---
> 
> In distro's aiming to support appliances intended for untrusted
> users (game-console manufaturers, mobile-phone creators,
> "walled garden" platforms), you'll likely find
> those options being set to "1", by default, during the
> bootup process.
> 
> Being about links of both varieties they are likely to have
> interactions with samba's processing - so you might want to
> ensure those options are set to values that work in your
> setup.
> 
> Hopefully this will help lessen the work you need to do
> to get around those imposing different (and functionality
> breaking) security models -- at least for now...
> 
> 
> Linda Walsh