[tech] Allowing wide symlinks in Samba shares

[James French]

Hi James,

You've hit the nail on the head re: why wide links should be left off. To
explore this a bit further though, we're an abnormal use case and don't
have the usual risks that article refers to.

In most environments, the only access users would have to the server is
through Samba so anything that lives outside of a file share they can see
should be invisible to them. If wide links and unix extensions are both on
(which used to be possible back in the Samba 2/3 days) you could get access
to things you shouldn't be able to read. The TLDR of your link (for those
who haven't read it) is its as easy as mount the share with with unix
extensions, make a link, then remount without them and grab the data the
link points to.

What makes us a little different is that UCC members already have shell
access to the file server and can grab any file they have read access to
already. In theory wide links don't expose any files at a higher level of
access than our users already have. The risk is it adds the possibility of
some security flaw in Samba that allows for privilege escalation. Turning
them on exposes more surface area to potentially attack but that's probably
an acceptable risk in the context of UCC's /away file server - the whole
point /away and /home are separate is to manage other existing risks that
are present with NFS and /away.

That said, unix extensions are nice for everything else they bring for
clients that support them. It is better to leave them on if we can come up
with another solution. (In reality though I don't know how many non-windows
clients are using Samba to get at /away, I'd hazard it's a rather short
list). If it really comes to it, I'd offer that adding working
Thunderbird/Firefox profile sharing is probably a better user experience
for a greater number people so it's not something I'd strongly argue
against.

Another options you might want to explore is adding a share for the
.mozilla folder a path of %h/.mozilla on a share will give each user access
to their own folder. From there you could look at a mount script or
relocating the profile location in windows. It's been a long time since I
poked about with Firefox/Thunderbird's profile, so apologies if that can't
be done.

Regards,
James

On Mon, 19 Aug 2019 at 23:28, James Arcus <jimbo at ucc.asn.au> wrote:

> Hi all,
>
> I was just tinkering around tonight trying to allow for sharing the same
> Firefox & Thunderbird profile between Windows and Linux on the clubroom
> machines. My plan of attack was to create a symlink from the relevant
> locations in AppData on the Windows profiles that link back to the
> .mozilla/.thunderbird folders in my /away.
>
> Samba on molmol would not follow my symlinks because they lead outside
> the share (so-called "wide links") and wide links are disabled when
> Samba Unix extensions are enabled. The intention of this is to prevent a
> vulnerability where a Unix client creates a symlink which is then
> evaluated by the Samba server. See
> https://www.samba.org/samba/news/symlink_attack.html for more.
>
> Disabling Unix extensions would allow my plan to work (as I verified),
> but does not necessarily fix the vulnerability. Given that UCC users can
> edit the contents of their Windows profiles freely from our user
> servers, I believe the same problem would exist there.
>
> For that reason, I've left wide links explicitly disabled with a
> comment. I'm not sure if my above assumption holds, so I'd appreciate
> any knowledge people have. Either that, or more investigation is needed.
> For example, if the "exploit" only allows reading files outside of the
> share that users would be able to access by logging directly in to
> molmol, that presents little issue. But if it allows any sort of writing
> or bypassing ACLs, then that's obviously more serious.
>
> Additionally, if there's another way to go about what I'm trying to
> achieve, then hearing that would be great too.
>
> Cheers,
>
> James [MPT]
>
> _______________________________________________
> List Archives: http://lists.ucc.asn.au/pipermail/tech
>
> Unsubscribe here:
> https://lists.ucc.gu.uwa.edu.au/mailman/options/tech/frenchie%40ucc.gu.uwa.edu.au
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20190820/07d475bc/attachment-0001.htm