3

If a file can only be read by its owner (400), is this any more secure than that file having read write permissions?

At best wouldn't this just help prevent you making stupid mistakes with your own files, rather than add any actual security? If you own a file, then you can alter its permissions. So if someone malicious gained access to a user, then having a file owned by that user set to 400 wouldn't prevent the attacker changing permissions on the file and writing to it?

Is there any security gained by having a file not writeable by its owner?

Dom
  • 231
  • richacl which does not exist yet, provides a way to prevent a file from being deleted. As does setting the immutable attribute (though most users can not do the latter, so is also a security risk). see https://unix.stackexchange.com/a/101269/4778 – ctrl-alt-delor Jan 31 '18 at 23:10

3 Answers3

3

If your threat model is binary — either the user account is not compromised or it is fully compromised (arbitrary command execution) — there isn't any difference. As you note, the attacker can just chmod u+w the file.

Partial compromise, however, can happen. E.g., if the attacker only gains "write to any file", then he can't write to the 0400 file. This is of questionable benefit in a lot of cases though — "write to any file" can often be elevated to arbitrary command fairly easily (e.g., write to ~/.bashrc).

Further, with write permission on the parent directory, you can still delete (unlink) a mode 0400 file. Meaning an attacker could delete the existing file and put a new one in place using the same name.

The one "security" use that comes to mind is a FTP (etc.) dropbox. You could put a README file in there, mode 0400. If your dropbox parent directory is set to a+rwxt, then everyone can add new files there (and due to +t) only delete files they own. So your README would be protected.

So I think overall it's a prevent accidents feature more than a security feature.

derobert
  • 109,670
2

Stupid mistakes destroy data. Protecting against stupid mistakes may save your data. Not having the write permission set on files you actually really want to keep is in the same category as not automatically using -f on rm, having rm complain to you if you accidentally try rm -r /, and not running your shell as root all the time. None of them are necessary, if you know what you're doing, but all of them might be useful in one situation or another.

But well, security vulnerabilities start small. User input may be used to decide on a file name to access, and if unsanitized, they may be able to cajole the program to accessing something that isn't meant to be accessed by end users. (Something like the classic ../../../passwd stuff.)

If an important file was kept without write permission, just being able to decide on the file name wouldn't allow writing said file. How much this matters, depends on what other files they might rewrite, though. (And really, better fix those uses of unsanitized inputs.)

ilkkachu
  • 138,973
0

In a nutshell, no, you are not gaining anything worth your effort. As you rightly mentioned, anyone who managed to read the file can also change its permissions.

There is always a security vs usability balance to take into account, and in this case I struggle to even see a gain, let alone gauge it against the effort of maintaining this solution.

Pedro
  • 1,891
  • 1
  • 13
  • 23