Claimed Zero Day exploit in Samba.
idra at samba.org
Sat Feb 6 13:44:41 MST 2010
On Sat, 2010-02-06 at 14:58 -0500, Michael Gilbert wrote:
> On Sat, 06 Feb 2010 14:31:29 -0500 simo wrote:
> > On Sat, 2010-02-06 at 14:24 -0500, Michael Gilbert wrote:
> > > On Sat, 06 Feb 2010 14:12:38 -0500 simo wrote:
> > > > > It would be feature-complete for users and administrators to control whether a
> > > > > remote user is trying to link outside his share because a user might want to
> > > > > link a directory in his own share, and an administrator might want to link a
> > > > > directory for users inside their shares.
> > > >
> > > > Unfortunately it is not possible to have your cake and eat it too. If
> > > > you want unix extensions and you do not want to severely limit what can
> > > > be done with it, then you must allow to create any symbolic link.
> > >
> > > like i said before and concurred by Jeremy, the ideal (but potentially
> > > very complex) solution is to detect when remote users attempt to jump to
> > > a target outside of their authorized shares and prevent that.
> > You are describing the option "wide links = no" as far as I can
> > understand. Unless you mean to consider as "authorized", file system
> > areas that are exposed by other shares. In that case I'd say that is
> > indeed too complex to build something that will work correctly in all
> > cases.
> this message:
> it may be a matter of automatically denying all unauthorized paths,
> and providing a way for the local admin to allow specific paths.
This is much more easily achieved with a MAC system like Selinux.
I don't think we want to do something like MAC controls within samba.
Unless it comes out that lots of people really do need both wide links
and unix extensions at the same time and can't use any of the
workarounds posted in this thread, it doesn't make sense to add
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical