Accessing Legacy Windows (SMB/Samba) Shares...

IanSav · Post by **IanSav** » Tue Aug 25, 2015 12:06

Hi All,

I am running the latest (2015-08-20 15:11) beta firmware on my T3 and new T4. On the T4 I find that I can not access SMB (Windows) shares coming from Windows XP or other older legacy systems. The mount happens but the file system is inaccessible. It appears that the underlying code is generating an error along the lines of "Operation not permitted" for these older shares.

This can be worked around by adding the a mount option "sec=ntlm" to the current mount options. This allows the newer code to make a valid connection to older style Windows shares.

I don't know if this is actually a bug or simply technology moving on but I believe the above suggestion rates as a hack or trick that may help others to get around the issue.

Regards,
Ian.

peteru · Post by **peteru** » Wed Aug 26, 2015 01:12

Definitely in the category of "hack/useful tip" for a legacy (unsupported by anyone) operating system. I am not sure whether it is a good idea to include that mount option by default. If you would like to summarise the pros and cons of doing so, I'm open to making changes to the default. The basic rule of thumb being that enabling any legacy options should not compromise / have negative impact on systems that are using current / supported operating systems. "If in doubt, leave it out."

IanSav · Post by **IanSav** » Wed Aug 26, 2015 01:34

Hi PeterU,

The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem. The builds of Samba appear to be the same. The only obvious difference is the kernel. The T3 is using "Linux t3 3.6.0 #1 SMP Thu Aug 6 23:46:04 AEST 2015 mips GNU/Linux" while the T4 uses "Linux t4 3.14.2 #1 SMP Thu Jul 23 01:49:02 AEST 2015 mips GNU/Linux". Are there any build differences between the two?

From the limited testing I performed I had issues connecting to Windows XP machines and ReadyNAS NAS boxes. Connections to Windows 7 appeared to work okay. I think all the NAS units I tried were *not* running the latest firmware (if it ain't broken don't fix it

).

I wouldn't advocate setting this option by default until we fully understand the problem and any possible security implications. An obvious first question could be does *anyone* else see this problem?

Having a bit of a Google around ('smb mount problem "Operation not supported"' then also added "sec=") found the following - and lots more:
https://bugzilla.samba.org/show_bug.cgi?id=8914 (search the page for "Operation not supported")
http://unix.stackexchange.com/questions ... -smbclient
http://askubuntu.com/questions/354235/f ... oing-wrong
http://ubuntuforums.org/showthread.php?t=947858
https://lists.samba.org/archive/samba/2 ... 64407.html
In most/all cases a "sec=" option appears to be required to fix the problem.

Regards,
Ian.

IanB · Post by **IanB** » Wed Aug 26, 2015 18:02

Seems the consensus is get used to it. The power that be have decreed NTLM is now a legacy protocol.

God I really miss Cobol, it was really good way to provide useful and harmless employment for the great unwashed. Now that great unwashed try their hand at system programming and royally fsck the world over.

IanSav · Post by **IanSav** » Wed Aug 26, 2015 18:10

Hi IanB,

So what is your suggestion for Beyonwiz? Should the "sec=ntlm" be added by default or should the kernel minimum security level be adjusted to the previous level?

Regards,
Ian.

peteru · Post by **peteru** » Wed Aug 26, 2015 18:57

I'm inclined to take the pragmatic approach and steer towards maximum compatibility (and thus better user experience), as long as doing so does not prevent proper interoperability with current and emerging OSes.

IanSav · Post by **IanSav** » Wed Aug 26, 2015 18:59

Hi PeterU,

I would welcome an ease of use decision.

Will you do it as a mount command option, as posted, or lower the minimum security threshold?

Regards,
Ian.

peteru · Post by **peteru** » Wed Aug 26, 2015 19:06

My preferred approach for this particular fix would be to put it as close to the user (and as visible) as is practical. That probably implies changing the default mount options that are presented in the GUI. This gives the clued users a mechanism to change the option.

MrQuade · Post by **MrQuade** » Wed Aug 26, 2015 19:53

A tick box in the mount options screen for "legacy shares"?

I've seen plenty of other options like that in BIOSs and the like that simply say "enable this if you run Windows XP".

IanSav · Post by **IanSav** » Wed Aug 26, 2015 23:11

Hi MrQuade,

MrQuade wrote:A tick box in the mount options screen for "legacy shares"?

Nice!

MrQuade wrote:I've seen plenty of other options like that in BIOSs and the like that simply say "enable this if you run Windows XP".

Or older NASs! (Like my ReadyNAS units.)

Regards,
Ian.

IanSav · Post by **IanSav** » Wed Aug 26, 2015 23:49

Hi,

Thinking about MrQuade's tick box suggestion a bit more and I think he is onto a very good idea. Perhaps all the common mount options should be removed from the "Mount options" setting and made a list of tick box selections. The list of options can change based on the type of mount selected. Each option could then be accompanied by a text description that describes the option and why it could or should be used. The "Mount options" entry could be renamed "Additional mount options" and be put at the end of the list of tick boxes for advanced users who know exactly what options they want to use. (The description text could list all the options the version of Samba in use can support.)

This would make the whole mount system easier for the non technical user to manage while still allowing "power" users to fully control the option.

Regards,
Ian.

peteru · Post by **peteru** » Thu Aug 27, 2015 00:54

Sounds like a big job, but if you want to have a go, I'll review the pull-request. Of course, such a massive change will take longer to review and merge.

IanSav · Post by **IanSav** » Thu Aug 27, 2015 01:32

Hi PeterU,

Tell me about it. Some of my pull requests have been waiting for well over a month!

I will have a look at this after I finish my Menu.py renovation and get my OverlayHD skin ready for public beta testing.

Regards,
Ian.

IanB · Post by **IanB** » Thu Aug 27, 2015 09:27

Geez, you guys always seem to reach for the sledge hammer. Stringing a whole lot of poxy application code together to fix bad system defaults imposed by Nazi XP killers.

IanB wrote:Seems the consensus is get used to it. The power that be have decreed NTLM is now a legacy protocol.

Apparently the policy change is in the kernel driver, fs/cifs/cifsglob.h The old SecurityFlags default was 0x7, the new is 0x85.

A more sensible default should have been 0x87, thus allowing NTLMSSP as a new addition. But some fool really wants to make Windows XP and all the other software that emulates it not work without a lot of research and special hacks.

I tested on my T3 thus :-

Code: Select all

cat /proc/fs/cifs/SecurityFlags
0x7
# Everything works as per normal

>/proc/fs/cifs/SecurityFlags echo 0x85
cat /proc/fs/cifs/SecurityFlags
0x85
# Thing become FUBAR, as expected.

>/proc/fs/cifs/SecurityFlags echo 0x7
cat /proc/fs/cifs/SecurityFlags
0x7
# Everything works as per normal again

Perhaps a T4 owner can test and report, I suggest trying both values 0x7 and 0x87.

From Re: [opensuse] CIFS - where/how is /proc/fs/cifs/SecurityFlags set?

Re: [opensuse] CIFS - where/how is /proc/fs/cifs/SecurityFlags set?

From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Date: Tue, 07 Jan 2014 13:54:47 -0600
Message-id: <52CC5B87.6030806@suddenlinkmail.com>

On 01/06/2014 10:13 PM, Andrey Borzenkov wrote:

By whom?

fs/cifs/cifsglob.h:#define CIFSSEC_DEF (CIFSSEC_MAY_SIGN |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)

Andrey,

Thank you! That was it. If you check 'cat /proc/fs/cifs/SecurityFlags' you
will find 0x85 which is the current default:

CIFSSEC_MAY_SIGN 0x00001
CIFSSEC_MAY_NTLMV2 0x00004
CIFSSEC_MAY_NTLMSSP 0x00080 /* raw ntlmssp with ntlmv2 */
-------
0x00085

for older version it was most likely:

CIFSSEC_MAY_SIGN 0x00001
CIFSSEC_MAY_NTLM 0x00002
CIFSSEC_MAY_NTLMV2 0x00004
-------
0x00007

--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

peteru · Post by **peteru** » Thu Aug 27, 2015 10:40

The big job isn't in making it work by using different default options. The big job I was referring to is the apparent desire to completely rework the user interface, which IMHO is an unrelated task. But, if there are people willing to go into the effort of improving the user interface, I'm not going to stand in their way. As long as the design makes sense and the code to support it is of reasonable quality, I'm happy to take contributions.

IanSav · Post by **IanSav** » Thu Aug 27, 2015 11:23

Hi PeterU,

But if IanB's solution is a fast fix to the underlying issue then why not go for it. UI improvements can come later.

Regards,
Ian.

IanSav · Post by **IanSav** » Thu Aug 27, 2015 13:27

Hi,

I tried the commands Ian suggested on my T4 and obtained some surprising results:

Code: Select all

root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x85
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x7
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x85
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 1
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x5005
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 2
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x0
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 3
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 4
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x0
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 5
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x85
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 133
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x87
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 135
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1

It looks like something might be very wrong at a kernel level.

Regards,
Ian.

IanB · Post by **IanB** » Thu Aug 27, 2015 15:30

Some archaeology :-

The CIFS SecurityFlags default changed at the initial kernel version 3.8 to 0x81=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP) and eventually changed to 0x85=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP) some time between then and now.

Also the parsing code behind /proc/fs/cifs/SecurityFlags changed at the same time. (see below)

Apparently if one does ">/proc/fs/cifs/cifsFYI echo 1" then extra debug info will be written to dmesg so we might get a clue as to why we cannot set desirable values to /proc/fs/cifs/SecurityFlags.

The 0x5005 for 1 and 0x85 for 0 values are obviously from the Boolean parse code at the top, " bv ? CIFSSEC_MAX : CIFSSEC_DEF;"

Possibly the cifs_debug.c code gets borked and then gets fixed again between 3.7 and now, but both code snippets below look good.

PeterU what cifs_debug.c did you build the T4 kernel with?

/fs/cifs/cifs_debug.c previous version 3.7

Code: Select all

581 static ssize_t cifs_security_flags_proc_write(struct file *file,
582                 const char __user *buffer, size_t count, loff_t *ppos)
583 {
....
593         if (copy_from_user(flags_string, buffer, count))
594                 return -EFAULT;
595 
596         if (count < 3) {
597                 /* single char or single char followed by null */
598                 c = flags_string[0];
599                 if (c == '' || c == 'n' || c == 'N') {
600                         global_secflags = CIFSSEC_DEF; /* default */
601                         return count;
602                 } else if (c == '1' || c == 'y' || c == 'Y') {
603                         global_secflags = CIFSSEC_MAX;
604                         return count;
605                 } else if (!isdigit(c)) {
606                         cERROR(1, "invalid flag %c", c);
607                         return -EINVAL;
608                 }
609         }
610         /* else we have a number */
611 
612         flags = simple_strtoul(flags_string, NULL, 0);
613 
614         cFYI(1, "sec flags 0x%x", flags);

/fs/cifs/cifs_debug.c latest

Code: Select all

619 static ssize_t cifs_security_flags_proc_write(struct file *file,
620                 const char __user *buffer, size_t count, loff_t *ppos)
621 {
...
633         if (copy_from_user(flags_string, buffer, count))
634                 return -EFAULT;
635 
636         if (count < 3) {
637                 /* single char or single char followed by null */
638                 c = flags_string[0];
639                 if (strtobool(&c, &bv) == 0) {
640                         global_secflags = bv ? CIFSSEC_MAX : CIFSSEC_DEF;
641                         return count;
642                 } else if (!isdigit(c)) {
643                         cifs_dbg(VFS, "Invalid SecurityFlags: %s\n",
644                                         flags_string);
645                         return -EINVAL;
646                 }
647         }
648 
649         /* else we have a number */
650         rc = kstrtouint(flags_string, 0, &flags);
651         if (rc) {
652                 cifs_dbg(VFS, "Invalid SecurityFlags: %s\n",
653                                 flags_string);
654                 return rc;
655         }
656 
657         cifs_dbg(FYI, "sec flags 0x%x\n", flags);

peteru · Post by **peteru** » Fri Aug 28, 2015 01:45

Let's just go with the mount flag, path of least resistance.

IanSav · Post by **IanSav** » Fri Aug 28, 2015 13:00

Hi PeterU,

peteru wrote:Let's just go with the mount flag, path of least resistance.

But most user inconvenience.

Regards,
Ian.

IanB · Post by **IanB** » Sat Aug 29, 2015 09:00

IanB wrote:PeterU what cifs_debug.c did you build the T4 kernel with?

I assume it was this one bcm7425-linux-3.14.2-20141120.tgz

peteru wrote:Let's just go with the mount flag, path of least resistance.

Hmmm!

I organised a session with a friends T4 to investigate further, and yes IanSav's results above when trying to set /proc/fs/cifs/SecurityFlags does for many cases indeed result either 0x0 or 0x1 values. Most interesting is that the cases that do work correctly are when setting the secure level CIFSSEC_MUST_* values. i.e. CIFSSEC_MUST_NTLM, 0x02002.

And looking at the code, we find that when compiled without the CONFIG_CIFS_WEAK_PW_HASH config option the flags do indeed get nuked at line 619 of cifs_debug.c

cifsglob.h line 1423
#define CIFSSEC_MUST_LANMAN 0
cifs_debug.c line 618
else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
____*flags = CIFSSEC_MUST_LANMAN;

Yes (*flags & 0 == 0) is always true, so *flags=0; always happens.

So the solution would appear to be to include the CONFIG_CIFS_WEAK_PW_HASH option in the next kernel build. And it would also be helpful to include CONFIG_CIFS_DEBUG to allow dmesg output.

Then we should be setting /proc/fs/cifs/SecurityFlags to 0xB7 to maximise support for all possible SMB servers.

Confirm version and build options :- Yes 2.02 and no Feature at all.

Code: Select all

# cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.02
Features:
Active VFS Requests: 0
Servers:

cifs_debug.c lines 600 to 624 :-

Code: Select all

/*
 * Ensure that if someone sets a MUST flag, that we disable all other MAY
 * flags except for the ones corresponding to the given MUST flag. If there are
 * multiple MUST flags, then try to prefer more secure ones.
 */
static void
cifs_security_flags_handle_must_flags(unsigned int *flags)
{
	unsigned int signflags = *flags & CIFSSEC_MUST_SIGN;

	if ((*flags & CIFSSEC_MUST_KRB5) == CIFSSEC_MUST_KRB5)
		*flags = CIFSSEC_MUST_KRB5;
	else if ((*flags & CIFSSEC_MUST_NTLMSSP) == CIFSSEC_MUST_NTLMSSP)
		*flags = CIFSSEC_MUST_NTLMSSP;
	else if ((*flags & CIFSSEC_MUST_NTLMV2) == CIFSSEC_MUST_NTLMV2)
		*flags = CIFSSEC_MUST_NTLMV2;
	else if ((*flags & CIFSSEC_MUST_NTLM) == CIFSSEC_MUST_NTLM)
		*flags = CIFSSEC_MUST_NTLM;
	else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
		*flags = CIFSSEC_MUST_LANMAN;
	else if ((*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
		*flags = CIFSSEC_MUST_PLNTXT;

	*flags |= signflags;
}

cifsglob.h lines 1414 to 1430 :-

Code: Select all

#ifdef CONFIG_CIFS_WEAK_PW_HASH
#define   CIFSSEC_MUST_LANMAN	0x10010
#define   CIFSSEC_MUST_PLNTXT	0x20020
#ifdef CONFIG_CIFS_UPCALL
#define   CIFSSEC_MASK          0xBF0BF /* allows weak security but also krb5 */
#else
#define   CIFSSEC_MASK          0xB70B7 /* current flags supported if weak */
#endif /* UPCALL */
#else /* do not allow weak pw hash */
#define   CIFSSEC_MUST_LANMAN	0
#define   CIFSSEC_MUST_PLNTXT	0
#ifdef CONFIG_CIFS_UPCALL
#define   CIFSSEC_MASK          0x8F08F /* flags supported if no weak allowed */
#else
#define	  CIFSSEC_MASK          0x87087 /* flags supported if no weak allowed */
#endif /* UPCALL */
#endif /* WEAK_PW_HASH */

peteru · Post by **peteru** » Sat Aug 29, 2015 17:12

I don't understand why you would find it preferable to make changes to the kernel rather than add an option to the user interface. Maybe I don't have the whole picture here. My understanding is that legacy SMB servers (as well as modern SMB servers) will work if the CIFS filesystem is passed the ntlm mount option. Let's just add that to the default mount options that enigma2 presents for CIFS mounts and we're done.

IanB · Post by **IanB** » Sat Aug 29, 2015 18:40

Because the code in the cifs_debug.c you used to build your latest kernel is broken!

Adding workaround code to enigma to fix a kernel driver bug when I have given you the kernel driver fix is just plain wrong. And hacking the client mount options will defeats the security policy when the kernel cifs driver is finally fixed.

You are supposed to be able to set /proc/fs/cifs/SecurityFlags to implement the security policy appropriate to your needs, but we cannot because the cifs_debug.c you used to build your latest kernel is broken!

Also the the CIFS driver as built does not support LanMan authentication, so even if you do a sec=lanman on your mount command it will not work.

Setting the kernel config option CONFIG_CIFS_WEAK_PW_HASH solves both problems, it includes LanMan authentication and avoids the set /proc/fs/cifs/SecurityFlags bug.

Also you are supposed to control kernel logging of the CIFS driver with /proc/fs/cifs/cifsFYI but without the kernel config option CONFIG_CIFS_DEBUG nothing happens!

All this works properly and correctly on the older CIFS driver used on the T3. In order to maintain functionality we now need to enable some config options. The current development path of the cifs driver seems to be a little broken.

peteru · Post by **peteru** » Tue Sep 01, 2015 01:22

CONFIG_CIFS_WEAK_PW_HASH enables LanMan (OS/2 and Win 95 level security), which is not what IanSav was after. He was after NTLM for Win XP level of compatibility. He also said that adding the "sec=ntlm" option did solve the issue.

I really don't see much point in rebuilding the kernel for 20+ year old operating system compatibility (OS/2 and Win95) when the fix for (the obsolete, but still deployed) WinXP can be achieved by adding a mount option.

What I am concerned about is compatibility with current versions of OSX and Windows. From what I gather, by forcing sec=ntlm, you will break connectivity to OSX SMB server, which will only speak sec=ntlmssp.

At this stage, I would like both WinXP and OSX users to test the behaviour they see when they:
1. Supply no additional mount options
2. Supply "sec=ntlm" mount option
3. Supply "sec=ntlmv2" mount option
4. Supply "sec=ntlmssp" mount option

I am hoping that "sec=ntlmv2" might be a middle ground that works in all cases, but I need empirical evidence. I don't run any Windows or OSX systems.

peteru · Post by **peteru** » Tue Sep 01, 2015 01:27

IanSav wrote:The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem.
...
Are there any build differences between the two?

There are no differences between the CIFS configuration options supplied to the kernel. However, the default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.

IanB · Post by **IanB** » Tue Sep 01, 2015 08:38

peteru wrote:CONFIG_CIFS_WEAK_PW_HASH enables LanMan (OS/2 and Win 95 level security), which is not what IanSav was after. He was after NTLM for Win XP level of compatibility. He also said that adding the "sec=ntlm" option did solve the issue.

I really don't see much point in rebuilding the kernel ....

NO! CONFIG_CIFS_WEAK_PW_HASH will bypass the bug that is stopping us setting /proc/fs/cifs/SecurityFlags to values other than 0 (illegal), 1, 0x85 and 0x?00?, the LanMan (OS/2 and Win 95 level security) is an incidental bonus. The other missing option CONFIG_CIFS_DEBUG should always be enabled so /proc/fs/cifs/cifsFYI can turn on the debug output.

It is becoming pretty obvious your answer really is "I really don't want to rebuild the kernel because it hard work."

Fair enough, just say it and I will stop wasting my time.

IanB · Post by **IanB** » Tue Sep 01, 2015 09:20

peteru wrote:
IanSav wrote:The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem.
...
Are there any build differences between the two?
There are no differences between the CIFS configuration options supplied to the kernel. However, the default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.

Yes both build have no special CIFS options.

No! The default for prior versions was Security mask 0x7 which is PacketSign, NTLM, NTLMV2. And logging was available.

The new default Security mask is 0x85 is PacketSign, NTLMV2, NTLMSSP. And logging is not available.

You cannot strictly map Security mask options to mount options. The Security mask options give a list of what is allowed to be tried automatically.

The mount options specify one single option to explicitly attempt. i.e. NTLM only or NTLMv2 only

peteru wrote:At this stage, I would like both WinXP and OSX users to test the behaviour they see when they:
1. Supply no additional mount options
2. Supply "sec=ntlm" mount option
3. Supply "sec=ntlmv2" mount option
4. Supply "sec=ntlmssp" mount option

I am hoping that "sec=ntlmv2" might be a middle ground that works in all cases, but I need empirical evidence. I don't run any Windows or OSX systems.

Pretty obvious how this is going to turn out.

1. no additional mount options -- servers that allow ntlmv2 or ntlmssp will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.

2. "sec=ntlm" mount option -- servers that allow ntlm will connect.
WinXp yes, >=Vista(without reg hack) no, things with suitable smb.conf option yes else no.

3. "sec=ntlmv2" mount option -- servers that allow ntlmv2will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.

4. "sec=ntlmssp" mount option -- servers that allow ntlmssp will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.

I believe the latest OSX default only permits ntlmssp connections, but it is apparently configurable.

Really the CIFS people are a pack of bastards, its none of their business which connections to allow or deny, that is the job of the server. Clients should just work (Tm.).

IanSav · Post by **IanSav** » Tue Sep 01, 2015 09:56

Hi PeterU,

I would like it to just work!

It is silly to allow users of the client to make a network connection and then have to find out why the connection appeared to work but no data is available. Then make users have to work out and understand the mechanics of the machine to which they are trying to connect. Then to work out what "sec=" option they may need at the client to make things work properly. This seems even more silly if the client end can be made to "just work" simply by having the builder set an option or two when building the system.

Security requirements really should be forced by the server and be optional at the client. If the server wants to share its connections via a clear text password then why should the client *force* a far more secure protocol. If the server doesn't care then why should the client? We are talking about home network connections where, in many cases, even usernames and passwords are not a desirable security measure. This is not a confidential corporate or business network with confidential data that *needs* to be protected. Even if it was it would be the servers that enforce the protection and not the clients.

Regards,
Ian.

peteru · Post by **peteru** » Tue Sep 01, 2015 11:57

IanB wrote:It is becoming pretty obvious your answer really is "I really don't want to rebuild the kernel because it hard work." Fair enough, just say it and I will stop wasting my time.

No. Rebuilding the kernel with a different config is a lot less work than changing enigma2. But, all the arguments you presented so far indicate that it's not the right approach. The Beyonwiz kernel has the same CIFS configuration as all the other enigma2 boxes out there. You have not presented a compelling argument for changing that configuration. On the other hand, IanSav's suggestion of supplying sec=ntlm seems like the best solution all around. The outstanding question is what effect will this have on OSX and other modern operating systems?

IanB wrote:CONFIG_CIFS_WEAK_PW_HASH will bypass the bug that is stopping us setting /proc/fs/cifs/SecurityFlags to values other than 0 (illegal), 1, 0x85 and 0x?00?, the LanMan (OS/2 and Win 95 level security) is an incidental bonus.

Well, in my book, that's completely arse about approach. If there is a bug in processing the flags, then a patch to fix that bug is a lot more preferable than turning on unrelated options just for their side effects. I don't really see an urgent need for such a patch. From my understanding, compatibility with WinXP can be achieved just by specifying sec=ntlm mount option to CIFS.

IanB wrote:The other missing option CONFIG_CIFS_DEBUG should always be enabled so /proc/fs/cifs/cifsFYI can turn on the debug output.

This is arguable too. In general, I would agree that a full blown server or desktop system with plenty of horsepower will benefit from having debug enabled. However, on a resource constrained embedded system, one has to be careful about enabling such things. At this stage we seem to have the root cause of WinXP incompatibility identified and a solution has been proposed. Let's establish the effectiveness of the proposed solution and it's effect on OSX and Win10.

peteru · Post by **peteru** » Tue Sep 01, 2015 12:07

I composed the above message last night / early this morning, but did not post it. It appears that in the meantime both Ians posted replies. It also appears that IanB has finally started to make some arguments that may be technically compelling. I will study those in more detail.

As an aside, it is not helpful to use emotionally charged language or aggressive tone. Calling people who work hard on implementing the solution "a pack of bastards" is not on.

IanB · Post by **IanB** » Tue Sep 01, 2015 12:56

peteru wrote:As an aside, it is not helpful to use emotionally charged language or aggressive tone. Calling people who work hard on implementing the solution "a pack of bastards" is not on.

If you read the cifs lists you see they are indeed working very hard with the goal to break default XP support and require special builds to access legacy systems under the guise of it is insecure therefore it should not be allowed. Okay to be fair not everybody, some are actually just trying to get packet signing and ntlmssp working properly, others not so much.

IanB · Post by **IanB** » Tue Sep 01, 2015 13:09

If you would rather a patch, easy, just delete 4 lines, 618 to 621 of cifs_debug.c

P.S. the CONFIG_CIFS_DEBUG options cost almost nothing until you echo 1 > /proc/fs/cifs/cifsFYI and that functionality used to be the default.

P.P.S and yes various enigma builds are starting to have all sorts of samba/cifs problems as they move to later kernel environments.

peteru · Post by **peteru** » Tue Sep 01, 2015 16:57

I will apply this patch to fix the handling of the MUST flags:

Code: Select all

From 7a1ceba071709d11271ebd921310b5a18404dd33 Mon Sep 17 00:00:00 2001
From: Niklas Cassel <niklas.cassel@axis.com>
Date: Thu, 22 Jan 2015 14:16:34 +0100
Subject: cifs: fix MUST SecurityFlags filtering

If CONFIG_CIFS_WEAK_PW_HASH is not set, CIFSSEC_MUST_LANMAN
and CIFSSEC_MUST_PLNTXT is defined as 0.

When setting new SecurityFlags without any MUST flags,
your flags would be overwritten with CIFSSEC_MUST_LANMAN (0).

Signed-off-by: Niklas Cassel <niklass@axis.com>
Signed-off-by: Steve French <steve.french@primarydata.com>

diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
index 9c56ef7..7febcf2 100644
--- a/fs/cifs/cifs_debug.c
+++ b/fs/cifs/cifs_debug.c
@@ -606,9 +606,11 @@ cifs_security_flags_handle_must_flags(unsigned int *flags)
 		*flags = CIFSSEC_MUST_NTLMV2;
 	else if ((*flags & CIFSSEC_MUST_NTLM) == CIFSSEC_MUST_NTLM)
 		*flags = CIFSSEC_MUST_NTLM;
-	else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
+	else if (CIFSSEC_MUST_LANMAN &&
+		 (*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
 		*flags = CIFSSEC_MUST_LANMAN;
-	else if ((*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
+	else if (CIFSSEC_MUST_PLNTXT &&
+		 (*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
 		*flags = CIFSSEC_MUST_PLNTXT;
 
 	*flags |= signflags;

On top of that, I'll also turn on NTLM as part of the defaults:

Code: Select all

Subject: cifs: Enable NTLM security to provide backwards compatibility with WinXP.

diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index c0f3718..81dcca3 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1431,7 +1431,7 @@ require use of the stronger protocol */
 #define   CIFSSEC_MUST_SEAL	0x40040 /* not supported yet */
 #define   CIFSSEC_MUST_NTLMSSP	0x80080 /* raw ntlmssp with ntlmv2 */
 
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
 #define   CIFSSEC_MAX (CIFSSEC_MUST_SIGN | CIFSSEC_MUST_NTLMV2)
 #define   CIFSSEC_AUTH_MASK (CIFSSEC_MAY_NTLM | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_LANMAN | CIFSSEC_MAY_PLNTXT | CIFSSEC_MAY_KRB5 | CIFSSEC_MAY_NTLMSSP)
 /*

I will turn on CONFIG_CIFS_DEBUG=y as well. At least for the next round of betas, which will be out after the current beta turns into a full official release.

IanB · Post by **IanB** » Tue Sep 01, 2015 17:31

Fair enough, pity this was such an effort.

Also glad you are hacking the driver default SecurityFlags to 0x87. => Just works! (Tm.)

And thanks for enabling the debug.

MrQuade · Post by **MrQuade** » Tue Sep 01, 2015 17:32

I realise this fix is just for authentication and security, but would any of the extra debugging data assist in debugging the TCP coalescing issues I have seen with modern Windows (7+) playing recordings over Samba using VLC?

jazza · Post by **jazza** » Sun Sep 06, 2015 10:25

Lol Title.

This is my favourite support request: " I understand it's legacy (old/outdated/due for replacement/unsupported), but I just want it to work.."

Followed by my new second favourite: " my BYOD (Bring Your Own Device [ie self managed]) gadget isn't working right, can a techie come configure it properly for me please...?"

Thanks for teh giggles.

peteru · Post by **peteru** » Sun Sep 06, 2015 14:59

So, now that the latest beta has these updates, can I please get a report as to the state of legacy networking?

Were the fixes effective? Can I consider this issue resolved?

IanSav · Post by **IanSav** » Sun Sep 06, 2015 15:13

Hi PeterU,

In summary, the fixes improve the situation but not fully / effectively.

The debugging and logging now works properly.

While I was party to the testing that was done I am not fully confident that I understood everything that happened. I believe that if the 0x80 bit is set in the mount bitmap then the cifs code breaks and does not allow the mount to work if the specific 0x80 mount fails. If that bit is not set the mounts work. From my understanding the code is failing to continue with the less secure mounts if the 0x80 mount fails. Given that the default mount mask includes the 0x80 bit then all mounts still fail by default.

Apparently this is another bug in the cifs code and not a problem with the patches you applied.

Hopefully IanB can chime in with more details and information when he is available.

Regards,
Ian.

IanB · Post by **IanB** » Sun Sep 06, 2015 18:07

Logging now works. Fixed!

The /proc/fs/cifs/SecurityFlags can now be set to any valid value. Fixed!

With the 0x2, CIFSSEC_MAY_NTLM , bit included connections to XP boxes now work correctly as before. i.e. 0x85 -> 0x87 Fixed!

Having the 0x80, CIFSSEC_MAY_NTLMSSP, bit breaks connection to the previous version 3.5.xx of Samba servers, because that 3.5.xx version implements a broken first attempt implementation of NtlmSSP. It works just well enough to bypass the early fail and move on to NtlmV2 logic. Setting SecurityFlags to 0x7 or mounting with sec=ntlmv2 or sec=ntlm works for this version. Older versions of samba that do not implement NtlmSSP, do correctly fail down to a lower security and "Just Works(Tm!)".

Tested against ReadyNas with samba versions, 3.5.8, 3.5.15 and 3.5.22.

The T4 was running samba 3.6.24.

Suggest running with SecurityFlags set to 0x7 might be the best "Just Works(Tm!)" solution while Samba 3.5.xx is still moderately popular.

prl · Post by **prl** » Sun Sep 06, 2015 18:23

It's had no effect on my main problem with Samba which is that the Network browser scan on the T series doesn't find the Samba server in my router.

But then I don't think that the changes should have made any difference to that.

IanB · Post by **IanB** » Sun Sep 06, 2015 18:29

What does :-

smbclient -L <Samba_ip_address>
Password: (blank)

show?

prl · Post by **prl** » Sun Sep 06, 2015 18:41

Code: Select all

root@beyonwizt3:/media/hdd/logs# smbclient -L 192.168.178.1
WARNING: The security=share option is deprecated
Enter root's password: 
dos charset 'CP850' unavailable - using ASCII
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Sharename       Type      Comment
        ---------       ----      -------
        Hellespont      Disk      
        IPC$            IPC       IPC Service (FRITZ!Box)
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
root@beyonwizt3:/media/hdd/logs#

It looks like the router's version of Samba is pretty ancient.

IanB · Post by **IanB** » Sun Sep 06, 2015 19:16

The anonymous login to the Samba server in your router does not have quite enough access to enumerate it's world.

Compare the output for my 3.0.37 samba server (xxx is elided) :-

Code: Select all

# smbclient -L 192.168.xxx.xxx
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Sharename       Type      Comment
        ---------       ----      -------
        DiskRO      Disk      The Disk
        IPC$            IPC       IPC Service (xxxxx)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Server               Comment
        ---------            -------
        BEYONWIZ-T32         SettopBox beyonwiz-t32 network services
        BEYONWIZ-T31         SettopBox beyonwiz-t31 network services
        Linux
        DX7300

        Workgroup            Master
        ---------            -------
        WORKGROUP            DX7300

Note my populated Server and Workgroup sections, yours are empty.

Compare when you use this:-

# smbclient -U <valid user> -L <Samba_ip_address>
Password: <valid password>

In your smb.conf what have you got your "guest account =" set to, mine is set to "plebb" a user I created for this purpose (no password, /bin/true shell).

prl · Post by **prl** » Sun Sep 06, 2015 19:27

xxx = elided username

Code: Select all

root@beyonwizt3:/media/hdd/logs# smbclient -L 192.168.178.1 -U xxx
WARNING: The security=share option is deprecated
Enter xxx's password: 
dos charset 'CP850' unavailable - using ASCII
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Sharename       Type      Comment
        ---------       ----      -------
        Hellespont      Disk      
        IPC$            IPC       IPC Service (FRITZ!Box)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
root@beyonwizt3:/media/hdd/logs#

IanB · Post by **IanB** » Sun Sep 06, 2015 20:03

Well that is certainly strange, the servers own name should at least appear in the server list. I could believe the workgroup list might be empty if there is no workgroup membership defined, but "Domain=[WORKGROUP]" is stated.

Can you fiddle with the smb.conf or is this a turn key router?

Does the router run a nmdb or is it one of those micro-hacked smbd only configs?

prl · Post by **prl** » Sun Sep 06, 2015 21:02

Its a turnkey router, but I think that with the current firmware I can telnet in and have a look round.

prl · Post by **prl** » Mon Sep 07, 2015 17:54

IanB wrote:...
In your smb.conf what have you got your "guest account =" set to, mine is set to "plebb" a user I created for this purpose (no password, /bin/true shell).

Code: Select all

[global]
workgroup = WORKGROUP
server string = FRITZ!Box
syslog = 0
username map = /var/tmp/users.map
encrypt passwords = true
passdb backend = smbpasswd
obey pam restrictions = yes
socket options = TCP_NODELAY
unix charset = UTF8
max stat cache size = 64
mangled names = no
bind interfaces only = yes
interfaces = lan
security = user
guest account = root
null passwords = yes
time server = yes
[Hellespont]
 path = /var/media/ftp
 read only = no
 username = xxx, yyy, zzz # not their real names
 valid users = xxx, yyy, zzz # not their real names
 create mask = 0777
 force create mode = 0777
 directory mask = 0777
 force directory mode = 0777

The root user has a non-matchable password entry in (slash)etc/passwd and /etc/shadow and the shell is /bin/sh. That configuration is as it is out of the box.

Apologies about the (slash)etc/passwd rubbish, but if I actually put a '/' in there, the stupid forum software accuses me of mounting an RFI/LFI file inclusion attack and won't let me post. Even more stupid is that it's apparently OK with /etc/shadow where the actually interesting stuff is stashed

IanB · Post by **IanB** » Mon Sep 07, 2015 18:12

Looks pretty much okay.

Is a nmbd running?

Slightly strange "guest account = root", but we tried with a valid user/pass so it's not that.

prl · Post by **prl** » Mon Sep 07, 2015 19:11

smdb, not nmdb

About the Forum

Join us