linux - How does an operating system prevent an unprivileged process from executing a privileged instruction?

09
2014-02
  • learner

    In Unix,

    if you are a guest user and did:

    chmod 777 /

    It would fail.

    But how does this internally happen at the hardware level?

    So far, I think this is what happens:

    • The OS tries to execute that instruction.
    • Information about permissions is perhaps somewhere in secondary memory. So it would issue a write instruction.
    • Before 2, It would check if the user is privileged to do this. If he isn't it would just issue an error message.

    Is this how it happens, or is an interrupt raised when such a situation arises? Is there a routine in the ISR table in main memory corresponding to unprivileged instructions?

    • Answers
  • Ignacio Vazquez-Abrams

    chmod is a filesystem operation, not a privileged instruction. Filesystem permissions are not handled at the hardware level. The software (specifically the OS) sees that the process invoking the system call does not have sufficient permissions to perform the operation on the filesystem object and the system call returns with a permission error.

  • sleske

    Actually, you are asking two different questions:

    1. How does an operating system prevent an unprivileged process from executing a privileged instruction?
    2. Why can an unprivileged process not invoke chmod 777 /?

    Answer for 2:

    chmod internally invokes a function from the libc (conveniently also called chmod()). This function checks whether the caller has sufficient privileges for the operation - if not, it returns error EPERM.

    The answer for 1 is more interesting:

    The exact mechanism depends on OS and hardware platform, but basically it's like this: All modern processors have built-in security features. This allows the OS to tell the processor: "run this program, but do not let it execute these privileged instructions". So the processor itself will enforce the restriction on allowed instructions. If the programm tries to execute a privileged instruction, the processor will pass control back to the OS, which will usually terminate the misbehaving program. For details, see e.g. https://en.wikipedia.org/wiki/Ring_%28computer_security%29


    • Related Question

    linux - removing write permission does not prevent root from writing to the file
  • laramichaels

    I just noticed on my Ubuntu machine (ext3 filesystem) that removing write permissions from a file does not keep root from writing to it.

    Is this a general rule of UNIX file permissions? Or specific to Ubuntu? Or a misconfiguration on my machine? 

    # touch abc
# chmod ugo-w abc
# python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open('abc','w').write('AAA\n')
>>> 
# cat abc
AAA

    Writing to the file fails (as expected) if I do this from my normal user account.

    1. Is this normal behavior?

    2. Is there a way to prevent root from accidentally writing to a file? (Preferably using normal filesystem mechanisms, not AppArmor, etc.)

    Please teach me about something that I most definitely don't understand.

    NOTE: I understand that root has total control over the system and can, eg, change the permissions on any file. My question is whether currently set permissions are enforced on code running as root. The idea is the root user preventing her/himself from accidentally writing to a file.

    NOTE: I also understand that one should not be logged in as root for normal operations. I just noticed this behavior and am asking you about it.


    • Related Answers
  • terdon

    1) This is a normal behaviour. root has rw access on all files at all times.

    2) You can protect a file even from root (not deliberate action, but accidental, anyway) by using

    chattr +i filename.ext

    That is "change attributes add immutable". To remove the protection:

    chattr -i filename.ext

    have a look at man chattr for more info

  • quack quixote

    1. Yes, this is normal. Root is god.

    2. Yes, there are ways to prevent root from overwriting files.

      • Set the immutable bit with chattr (+i sets, -i unsets). Requires root access, works only on ext2/ext3 (presumably ext4 too), but is otherwise practical.
      • Don't run apps as root. No root privs, no overwriting files. Use sudo to access system functions.
      • Unmount the filesystem. No mounted fs, no overwriting files. [*]
      • Turn off computer. No electricity, no overwriting files.

    These methods follow logically from #1. As you can see, the last two methods are generally not useful, in the same way that protecting Windows against viruses by unplugging the network is generally not useful. This is why root is dangerous.[+]

    [*] Discounting the possibility of "accidentally" writing directly to the block device, of course. Yes, root can do that. Yes, you can prevent that: disconnect the device.

    [+] This is also where those BOfH myths come from. They're not all myths.

  • dag729

    I think that as long as root is the superuser, and he can do anything, you cannot remove him any permission, also if you are the root. It is supposed to be the will of the root to prevent himself of doing or not an operation (such as write into a file, or open an application).

    So no, chances are you would only deactivate the root account, to prevent a bad use of it.

    Regards

    [note to self: ye shall be humble...maybe ye are wrong]

  • Area 51

    You can also restrict file access for the root user, by using Linux kernel "Capabilities": http://www.securityfocus.com/infocus/1400

    There is also the possibility of using SE-Linux or some other kernel patch to make some files immutable even to root.