Re: Users able to execute windows .exe though execute bit not set
On April 1, [EMAIL PROTECTED] said: I'm looking for some assistance regarding file permissions and the inability to stop the execution of a file even though the execute permission has not been set. Execute bits are a Unix concept. Windows will execute any file it can read that it understands the extension of and has a handler for. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. After explaining the situation to the machine clearly with appropriate use of a screwdriver... - Alan Cox
Re: Users able to execute windows .exe though execute bit not set
Nick, Perhaps you can explain how you would achieve your goals if the server was running Windows 2000 Server. If you can demonstrate a pure Windows solution maybe we could match that with Samba. - John T. On Tue, 1 Apr 2003, Nick Drouet wrote: I'm looking for some assistance regarding file permissions and the inability to stop the execution of a file even though the execute permission has not been set. Scenario I create a share. I copy the notepad.exe from a windows client onto the share. From Linux console: chown user notepad.exe chmod 600 notepad.exe From Windows client: I map a drive to the share and I am still able to run the notepad.exe file from the share, even though executable permissions aren't set... I can remove the executable flag via the Windows GUI and the same occurs. I've tried other executable files and the same occurs. If I chmod 222 to remove any read rights, then I get the access denied that I would expect. As far as user permissions are going, I've tried a number of options. Originally I had a samba server as a member of a Windows NT Domain, using Winbind to map user IDs. This also had ACL support with the 2.4.17acl kernel and permissions were being set fine on multiple users from the NT domain. I've stripped elements out until I now have just a samba server which is not part of a domain and my windows user is in the smbpasswd file with matching user Id and password. At all stages this problem occurs. I need to know if I'm doing something very dumb here but the ability to stop users running executables from a network share is critical. Clients are Windows 2000 / NT4 Samba versions that I've tried are 2.2.8 and 2.0.0.15 (RPM from SuSE installation CD). Linux distros that I've tried are SuSE 7.2 and Redhat 7.2 Does anyone have any light they could throw onto why this is happening? I've seen a few threads regarding this in the samba general but no replies so forgive if off topic slightly but could really do with some hints.. Relevant bits from my smb.conf are below. [global] workgroup = DOMAIN2 guest account = nobody keep alive = 30 os level = 2 kernel oplocks = false security = domain encrypt passwords = yes socket options = TCP_NODELAY map to guest = Bad User wins server = 192.168.1.80 netbios name = samba1 winbind uid = 1000-2000 winbind gid = 1000-2000 winbind cache time = 10 winbind separator = + password server = * log file = /var/log/samba log level = 1 [share3] path = /share3 comment = shared area read only = no browseable = yes -- John H Terpstra Email: [EMAIL PROTECTED]
Re: Users able to execute windows .exe though execute bit not set
On Tue, 1 Apr 2003, Ronan Waide wrote: On April 1, [EMAIL PROTECTED] said: I'm looking for some assistance regarding file permissions and the inability to stop the execution of a file even though the execute permission has not been set. Execute bits are a Unix concept. Windows will execute any file it can read that it understands the extension of and has a handler for. Hmmm, I did some testing a week or so ago, and found that removing the execute permission from ACLs on the file (esp inherited ones) prevents Win2K from executing the file, although it does open the file for read first. Since we have just added proper eXecute permission support to our (almost) NT ACLs in the file system, let me check this today to see what the deal is. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Users able to execute windows .exe though execute bit not set
On April 1, [EMAIL PROTECTED] said: Hmmm, I did some testing a week or so ago, and found that removing the execute permission from ACLs on the file (esp inherited ones) prevents Win2K from executing the file, although it does open the file for read first. Yep, turns out I opened my mouth without being completely sure of what I was saying :) Since we have just added proper eXecute permission support to our (almost) NT ACLs in the file system, let me check this today to see what the deal is. jmcd says it should work. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. for god's sake, give me some credit. i may be an egocentric jerk, but i'm not a COMPLETE asshole. - Meredith
Re: Users able to execute windows .exe though execute bit not set
On Tue, 1 Apr 2003, Jim McDonough wrote: Hmmm, I did some testing a week or so ago, and found that removing the execute permission from ACLs on the file (esp inherited ones) prevents Win2K from executing the file, although it does open the file for read first. Doesn't happen for me. It lets me execute a file for which I only have read access... Right, but I was testing Win2K against NT. I know that we will fail this test, as discussed on IRC because the POSIX open call does not allow you to specify O_EXEC ... so I will need to do other checks here. However, since our NFS code needs to check for X access, I can probably piggy back on this with an IOCTL. UGLY. We should probably have a torture test for this. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
RE: Users able to execute windows .exe though execute bit not set
You should note that the ACL system and the Unix permission bits are two different things. What you are actually talking about is the translation between the two. If the ACL system has Execute permission set for the user, then that user should be able to execute the program on the client. That determination is made on the client end. If the Unix execute bit is set, then a Unix user should be able to run that executable on the Unix host. My personal opinion is that there is no meaningful translation between the two, unless we are talking about Perl scripts, or something else which runs on both systems. If there is an ACL system as part of the server, I don't see any need to bother with the Unix execute bits, for Windows-only executables. The problem is compounded by the possibility that those bits have been used within Samba to store other functionality such as the DOS System or Hidden bits. Jeremy Allison is the one who can state this case better than I can. He gave a presentation at the CIFS conference in Bellevue, in August 2001 on this very subject. He should make the final determination on this. -Original Message- From: Ronan Waide [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 11:23 AM To: Richard Sharpe Cc: [EMAIL PROTECTED]; Nick Drouet Subject: Re: Users able to execute windows .exe though execute bit not set On April 1, [EMAIL PROTECTED] said: Hmmm, I did some testing a week or so ago, and found that removing the execute permission from ACLs on the file (esp inherited ones) prevents Win2K from executing the file, although it does open the file for read first. Yep, turns out I opened my mouth without being completely sure of what I was saying :) Since we have just added proper eXecute permission support to our (almost) NT ACLs in the file system, let me check this today to see what the deal is. jmcd says it should work. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. for god's sake, give me some credit. i may be an egocentric jerk, but i'm not a COMPLETE asshole. - Meredith
RE: Users able to execute windows .exe though execute bit not set
What is Windows is using to determine that it needs to do the executability test? There is no executable bit in Windows. There is the ACL entry, but nothing at the DOS level. That is, unless they are testing the file extension. What Windows would need is a marker that enables a file for execution, and a network request from the client which notifies the server that the file is being read for execution. Windows could compare the two, and deny the read if the file is not enabled. In any case, it has to trust the client not to read the file for non-execution, and then execute it. Since Windows is also the client, such a trustworthiness can be relied upon. I would not be surprised to learn that Samba does not do the executable test on files being read, since there is no reasonable place to store a Windows execution flag. (Perhaps this can be added as an extended attribute setting.) If Windows is testing the file extension instead, then Samba should be extended to do the same thing. -Original Message- From: Jim McDonough [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 12:03 PM To: John H Terpstra Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Nick Drouet Subject: Re: Users able to execute windows .exe though execute bit not set Perhaps you can explain how you would achieve your goals if the server was running Windows 2000 Server. If you can demonstrate a pure Windows solution maybe we could match that with Samba. John, I've checked it out and this is a real difference between Samba and NT or 2k. NT/2k both check the X permission, and we don't, because we rely on open(), and you can't request X access on open()... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
RE: Users able to execute windows .exe though execute bit not set
What is Windows is using to determine that it needs to do the executability test? There is no executable bit in Windows. There is the ACL entry, but nothing at the DOS level. That is, unless they are testing the file extension. It uses the ACL. It follows locally what's in the ACL, and the server will grant/deny the requested access based on what's in the ACL. It works. Folks have pointed out that you can just get around it by reading the file, copying it locally, and running it from there, but there are many companies out there that lock down all the workstations, and prevent local write access for this very reason. What Windows would need is a marker that enables a file for execution, and a network request from the client which notifies the server that the file is being read for execution. Windows could compare the two, and deny the read if the file is not enabled. In any case, it has to trust the client not to read the file for non-execution, and then execute it. Since Windows is also the client, such a trustworthiness can be relied upon. The ACL is this marker, and the network request NTCreateX will pass along whatever access you tell it, and windows clients tell it they want execute access. I detail the trust situation above. I would not be surprised to learn that Samba does not do the executable test on files being read, since there is no reasonable place to store a Windows execution flag. (Perhaps this can be added as an extended attribute setting.) If Windows is testing the file extension instead, then Samba should be extended to do the same thing. Samba does not test any of the bits, but rather relies on the OS to do the testing. This works fine for read and write, because open() allows you to specify them. You can't request X' permissions, though, so we'd have to explictly test it. The unix x bit is a perfectly reasonable place to store this, and unix has the same problems windows does...if you can read it, you can copy it and change the bits in your own copy. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
RE: Users able to execute windows .exe though execute bit not set
-Original Message- From: Jim McDonough [mailto:[EMAIL PROTECTED] The unix x bit is a perfectly reasonable place to store this, and unix has the same problems windows does...if you can read it, you can copy it and change the bits in your own copy. Isn't the UNIX x bit already taken? I thought it was being used to map one of the other DOS mode bits.
RE: Users able to execute windows .exe though execute bit not set
Perhaps you're thinking of the setuid/setgid/sticky bits. This is why I referred the question to Jeremy Allison. He (literally) wrote the book on this. I'd quote from his CIFS presentation, but I can't find it online, and I don't have my copy with me. There should also be some consideration of the security implications. If someone can use a Windows mount to push a file onto a Unix server, and get it's execute and setuid bits set, they could run the program as the Unix user who writes files on the share. It may not be much of a hole, but it is one. This is why I think there should be no mapping between Windows and Unix, and only an ACL which controls execute permission for Windows. The functionality would be there for both systems, but neither could easily affect the other. -Original Message- From: David Brodbeck [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 3:48 PM To: 'Jim McDonough'; Esh, Andrew Cc: John H Terpstra; [EMAIL PROTECTED]; Nick Drouet; [EMAIL PROTECTED] Subject: RE: Users able to execute windows .exe though execute bit not set -Original Message- From: Jim McDonough [mailto:[EMAIL PROTECTED] The unix x bit is a perfectly reasonable place to store this, and unix has the same problems windows does...if you can read it, you can copy it and change the bits in your own copy. Isn't the UNIX x bit already taken? I thought it was being used to map one of the other DOS mode bits.
