2

On Ubuntu, if you use (external) drives formatted as exFAT or NTFS, i.e. not ext4 or something made for the UNIX world, you may end up with a situation where all files are executable.

This is because the file systems may have other concepts of permissions, or none at all. And it is to faciliate sharing between multiple computers. That makes sense.

Usually, you can even adjust this behavior in the mount options. But with the default options, the drives are often auto-mounted with the behavior described above.

Could you consider this a security risk? Especially if it comes to non-technical users, who will only ever use the default mount options (e.g. your grandma whom you switched to Ubuntu).

You could probably say it very much depends on the contents of the drive. But why introduce the risk?

caw
  • 199
  • 1
  • 11
  • 2
    Execution restrictions are not a security feature in general. – forest Sep 27 '18 at 01:01
  • @forest Well, if it’s not a security feature, what is it? It’s grouped within the set of “permissions”, at least. Semantically, this suggests that it’s related to security. So would you say that “whatever you can read, you can execute”, and “you can just chmod it anyway”? So the executable bit is only for convenience to facilitate execution with fewer clicks? I would say it’s a GUI-wise security feature, just as a confirmation dialog is. Unexperienced users (or really, everyone) may run malicious code when double-clicking a file from a mail attachment – but only if the executable bit is set. – caw Sep 27 '18 at 06:51
  • Related: https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit and https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypassed-is-it-superfluous-or-whats-the – caw Sep 27 '18 at 07:00
  • @forest There are different aspects of security. Hard internal and technical guarantees in the kernel are *one* aspect. Preventing the average user from doing something silly via the GUI is *another* aspect, wouldn’t you agree? – caw Sep 28 '18 at 10:50
  • 1
    The `noexec` flag was created long before GUI security was ever considered. While it may have some limited security benefits (e.g. breaking some automated bots that try to download and execute a file in `/tmp`), it is not designed _for_ security. See also [this](https://security.stackexchange.com/a/66556/165253) answer as linked above. – forest Sep 28 '18 at 10:53
  • Do you know about the umask= mount option? This controls how the permissions are displayed on file systems that do not support UNIX permissions. – Alex Cannon Apr 17 '21 at 20:28

1 Answers1

0

The default is to auto mount the drive in read/write mode. There are no other evaluations or alterations with regard to executability. Nothing is going to auto-run if that's your concern.

Can someone execute a file from a mounted drive, certainly they can. That's the behavior most people want.

There are forensic builds that are configured to mount Read-Only in order to protect against modifications of the mounted device, but it's still possible to execute a file if you choose to do so.

No I don't consider this to be a security risk. Yes, someone can do foolish things within the constraints of their user permissions.

               ----------------

Ah, I see!

FAT16 and FAT32 do not have this behavior. ExFAT and NTFS do indeed mount with 'x' enabled. I had never noticed this before.

Yes this does strike me as potentially dangerous. I'll have to research this as to why it's ocurring.

           --------------

Good answer here:

https://askubuntu.com/questions/11840/how-do-i-use-chmod-on-an-ntfs-or-fat32-partition

user10216038
  • 7,552
  • 2
  • 16
  • 19
  • Thank you! I wasn’t under the impression that things could “auto-run” from a drive. But what do you think about a normal, non-technical, unexperienced user double-clicking an unknown (untrusted) file and this resulting in either (a) the file opening, if the executable bit is *not* set, or (b) the file being executed, if the executable bit *is* set? Isn’t that a security feature with modern computer usage and non-expert users in mind? – caw Sep 27 '18 at 07:03
  • 1
    Would you want the system to automatically change your file permissions to remove executable capability everytime you plugged in a drive? Potentially thousands of files? Should it change them back when it unmounts? Should it create a virtual mount without 'x'? Would it maintain a virtual ability to change 'x' as needed? Would you want to have to redo this everytime you plugged in? Many alternative implementations are possible, but consider the user ramifications. I'm annoyed that Windows 10 writes a file to my thumb drives when I plug one in. – user10216038 Sep 27 '18 at 21:56
  • Right now, the system automatically changes my file permissions to *add* executable capability every time I plug in a drive. So I don’t think that’s necessarily better. In both cases, the permissions are changed. You cannot avoid changing them when the file system cannot store them. Perhaps it would be better to err on the safe side, though. Or ask. Or have a setting. – caw Sep 28 '18 at 08:20