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

[Linda W]

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