[Samba] can't turn on wide links in homedir

[Linda Walsh]

Jeremy Allison wrote:
>  We needed to make it impossible to configure Samba insecurely.  At the
>  time this was proposed, it was posted to the list and no dissenting
>  voices were heard.
---

    Not exactly true -- as soon as this feature was available for testing
in a downloadable package, there were dissenting voices.   Proposing
patches or changes on 1 product that one is responsible for, out of the
100's to 1000's of packages (over 3600 on one machine I just checked),
that people use on their machines, AND expecting any representative or
informed response from those that will affected by such a patch, is
provincial, at best.

    When people were hit by this remote-management disabling patch, in
the first release that included it, there was, there was notable dissent.
dissent.

    It improved server security in the same way that ANY disabling of
remote- administration abilities will 'improve' server security -- i.e.
it may or it may result in creating worse problems.

    The 'bug'[sic],  was that a user could create a symlink in their home
dir to point to /etc/passwd.   Using that, they could allow /etc/passd to
be readable by anyone who had pass-through access on the user's home dir,
and the ability to read /etc/passwd.

  However, users who have their home directory on the server, as in one
some of the samba-suggested configurations where *nix security is
controlled by a samba PDC, could always manage symlinks remotely via ssh.
If a site expected users to be able to use directed links in specfic
shares, they could turn on wide-links for the share that needs them (on
which USERS may have no write access), while on user-writable shares,
wide-links would not be enabled.   This would be the expected way someone
would manage this feature.

  But limiting wide links to non-user-writeable shares was considered too
difficult for people to figure out.  And somehow, allowing wide-links to
function, ONLY on non-user-write-able shares was considered 'insecure'
(how?).

  Even though there was an easy solution t0 the problem, the solution was
server-wide disabling of wide-links on all shares, if  unix extensions
were enabled ---  something that did more harm than good and likely
*created* 'insecure samba configurations', for sites that needed that
functionality by had to work around it..

  Contrary to the assertion that server-wide disabling of 'wide links'
(an imprecise and non descriptive term that probably led to the problem
that arose in the first place!) resulted in disallowing 'insecure
configurations', It created some configs that were more secure, AND some
configs that were less secure.  

  Now there is the strong possiblity of another option with another bad
name being added to get around previously ill-chosen named options  in
order to allow 're-hardening' of security on sites that were 'made less
secure' the original disabling patch.

  ARG!...


  I  would like to put forth a possible alternative for consideration
(perhaps a bit late in the game), though perhaps a goal for a release in
the near future.  Better to say someting that  be accused later of saying
nothing...

Immediate:
   - Revert the original patch.
   - deprecate 'wide links'.
   - add new, descriptive term:
   
     allow symlinks outside share boundaries = (yes/no)

Or, longer term solution might be to add:


  permitted symlink targets = ...  veto symlink targets = ...

e.g.

  permitted symlink targets = /

  veto symlink targets  = /etc  /proc /sbin /dev  /root  /tmp

or

  permitted symlink targets = /home /Share /backup /bin ...

(excluding /etc, thus passwd, for example).

  Claiming that some options are 'insecure' - when used correctly is
confusing, as it leads one to wonder why is it that an option that is not
insecure on linux, IS insecure on samba...are there bugs in samba that
make it more insecure?

  Certainly, if options are unclear, then they should be renamed over
  time.

  Through a @allow_compat <prev version>.... options could be immediately
deprecated, and 're-allowed' for 2-3 releases (or some fixed time).

  But going with descriptions that label 'useful (and used) features' as
"insecure", when the opposite may be true for a given site is bound to
cause confusion and a desire to give multitudes of *worse* ways the samba
can be be abused even though it is claimed that it is impossible to
configure it "insecurely"...

I'm sure that wouldn't be appreciated, bug some might feel a need
to relate such configs, purely so that every useful samba config (or option)
can be "prohibited" in the name of protecting us...