4

One of the core pieces of security in Unix/Linux systems is limiting privileges by user. For instance, certain actions can only be done by the root user. In theory, this can keep a malicious process from causing too much harm.

But what mechanism enforces this?

As far as I know, there are basically two ways of password-protecting something:

  • Superficially: When Windows XP boots, it may ask for a password. Without the password, it won't let you log in, which might stop someone from accessing a file on the computer. But this only works if the attacker boots Windows; if they boot a different operating system and mount the hard drive, there is no protection on the file.
  • Cryptographically: Password management programs typically store passwords in a file. This file is encrypted with a "master password." Unless you supply the master password, the program not only will not, but truly cannot give you access to the file; it does not know how.

Which category do Unix/Linux user permissions fall under, and how is this enforced?

Improve this question
2
  • When we try to do something that requires sudo access and we don't have it, then OS refuses this is because we are trying execute operation on an inode, which is not our's. For example [user1@localhost ~]$ sudo chown -R user2:group2 Documents/ This will ask for sudo password and refuses if we don't have, just because inode permissions of /usr/bin/chown file does not belong to user1 in any ways (owner/group/other). Unix kernel can read and load a file into memory for execution only if it has access permission on the inodes the file points to.
    – sundeep
    Dec 27, 2012 at 15:46
  • if you can get a physical access it's different. Bypassing operating system authentication scheme isn't really difficult using the proper tool.
    – happy
    Dec 30, 2012 at 22:27

4 Answers 4

Reset to default
6

Linux user permissions are just a form of ACL, stored as data structure as part of the file system. They're enforced by the operating system, but not in any solid sense - a file system driver or OS that doesn't recognise Unix-style permissions will just ignore them. The same goes for Windows file permissions, which are ignored on Linux systems.

Transparent file-system encryption is done via a key stored in the users database, which is in turn encrypted by the user's password. When the user logs in, the password is used to decrypt the key, which can then be used to decrypt the file data.

Improve this answer
4
  • 2
    "a file system driver or OS that doesn't recognise Unix-style permissions will just ignore them." This is a good point. So this implies that malware is only stopped from editing, say, '/etc/hosts' because it goes through the OS to do so, and the OS refuses. If it could somehow bypass the OS, it could edit it.
    – Nathan Long
    Dec 27, 2012 at 14:49
  • 1
    @NathanLong Yep. A kernel-mode driver can totally ignore all forms of access control because it runs below that abstraction layer. An alternate OS would do the same because it doesn't recognise that access control mechanism.
    – Polynomial
    Dec 27, 2012 at 14:54
  • OK. But the protection is still useful because, unless someone can boot your machine themselves, their malware will have to be executed by the OS, and it will refuse most nasty behaviors? In other words, even if the restriction is just "because the OS said so," it's very hard to get malicious code run apart from the OS?
    – Nathan Long
    Dec 27, 2012 at 16:58
  • Yep. To load malicious kernel code at runtime (thereby modifying, not bypassing the OS), you need root access. And if you have that, then you can already run anything you want through the OS and you don't even need complicated kernel malware anymore. You can't really bypass the OS while it's online except by bugs in the OS or insecure features of hardware (read up on DMA by FireWire for quickly cracking running systems with physical access...)
    – us2012
    Dec 27, 2012 at 19:23
1

The first, Linux doesn't encrypt files by default, even ones only readable by root. I can wander up to any linux machine, throw in a knoppix cd and happily mount the HDD, gaining access to all files.

This is why we have things like dm_crypt to protect against physical-access threats.

Improve this answer
0

Most file systems and runs "superficially", but there are FS solutions that go "cryptographical" way too.

This actually applies to Windows too, when you mark file as "encrypted", EFS sub-system of NTFS kicks in and actually encrypts file so it no longer accessible without proper password, even if you gain access to physical disk from another environment.

Improve this answer
0

Revised based on the OP's clarification of the question. SuDo uses the password to verify(authenticate) your identity. It then checks a configuration policy file permissions table (for example, /var/db/sudo) to see if you are authorized to execute the command in question. If you pass both authentication and authorization, Sudo will permit you to execute the command in question with an elevated privilege. The specific details for the mechanism for elevated privilege are interesting, but probably beyond the scope of your question. You can find a fuller explanation at the Sudo man page (check your system for one that is more appropriate to whatever version of the OS you're running.)

The operating system.

The example you cite for "superficially" is merely an application that is password protected.

You don't cite the example of file protection on Windows - which would be the closest analogy. What prevents me from writing to c:\windows\system32\cmd.exe? Windows does.

One of the core functions of the operating system is to implement access control.

Are you asking "What mechanism implements user permissions?", or are you asking, "How to password protect something?" (both of your examples).

Improve this answer
1
  • I'm asking this: when I try to do something that requires sudo access and I don't have it, and the OS refuses, is it just refusing to do it as a matter of policy, or is it actually unable to do it? If the latter, why not? Does something have to be decrypted using the password in order for the action to proceed, for example?
    – Nathan Long
    Dec 27, 2012 at 14:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .