SETUID: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 3: | Line 3: | ||
Sometimes a user needs to do something which would not normally be permitted. One way to do this might be through a [[System_Calls|system call]]; another way might be via a running [[Daemons|daemon]]. In each case the O.S. software can verify if the request is allowable. | Sometimes a user needs to do something which would not normally be permitted. One way to do this might be through a [[System_Calls|system call]]; another way might be via a running [[Daemons|daemon]]. In each case the O.S. software can verify if the request is allowable. | ||
Another approach – sometimes necessary – is to start a new process | Another approach – sometimes necessary – is to start a new process to perform the service. This may imply that a user starts a process posing as a different user: possibly even as the [[Superuser|administrator]]. If an ordinary user was able to do this | ||
to perform the service. This may imply that a user starts a process | |||
posing as a different user: possibly even as the | |||
[[Superuser|administrator]]. If an ordinary user was able to do this | |||
with an arbitrary process then there could be a [[Security|security breach]]. | with an arbitrary process then there could be a [[Security|security breach]]. | ||
The [https://en.wikipedia.org/wiki/Unix Unix] approach is to extend the [[File_Permissions|file permissions]] of the process to cause the new process | The [https://en.wikipedia.org/wiki/Unix Unix] approach is to extend the [[File_Permissions|file permissions]] of the process to cause the new process to run as if its <em>owner</em> had started it, rather than the <em>user</em> who did actually invoke it. This means that a file <em>owned</em> by <code>root</code> can be executed <em>as</em> <code>root</code> by an ordinary user. Of course the real administrator has to set up this privilege and it should only be used when the application is trusted not to do harm. The Unix approach is the [https://en.wikipedia.org/wiki/Setuid <code>setuid</code>] bit in the [[File_Attributes|file’s attributes]]. | ||
to run as if its <em>owner</em> had started it, rather than the <em>user</em> who | |||
did actually invoke it. This means that a file <em>owned</em> by <code>root</code> can be executed <em>as</em> <code>root</code> by an ordinary user. Of course the real administrator has to set up this privilege and it should only be used | |||
when the application is trusted not to do harm. The Unix approach is the [https://en.wikipedia.org/wiki/Setuid <code>setuid</code>] bit in the [[File_Attributes|file’s attributes]]. | |||
A similar bit, <code>setgid</code>, allows the cloning of the owner’s <em>group</em> ID. | A similar bit, <code>setgid</code>, allows the cloning of the owner’s <em>group</em> ID. | ||
Note that this feature is not confined to gaining temporary <em>root</em> | Note that this feature is not confined to gaining temporary <em>root</em> privilege; it can be allowed by the owner of any executable file. | ||
privilege; it can be allowed by the owner of any executable file. | |||
---- | ---- | ||
=== A Trap for the Unwary === | === A Trap for the Unwary === | ||
Unix uses a [[PATH|search path]] to find a given file-name for | Unix uses a [[PATH|search path]] to find a given file-name for execution; a shell will execute the <em>first</em> name match it finds on its $PATH. You can discover which this is from a shell: for example to find the binary used to list a directory, type <code>which ls</code>. | ||
execution; a shell will execute the <em>first</em> name match it finds on its | |||
$PATH. You can discover which this is from a shell: for example to | |||
find the binary used to list a directory, type <code>which ls</code>. | |||
If the path can be intercepted, a user could unwittingly execute an unintended utility. A hacker could insert a script called (say) “ls” early in your search path which <em>you</em> would then invoke involuntarily. This could, for example, change your [[File_Permissions|file permissions]] – probably before invoking a | If the path can be intercepted, a user could unwittingly execute an unintended utility. A hacker could insert a script called (say) “ls” early in your search path which <em>you</em> would then invoke involuntarily. This could, for example, change your [[File_Permissions|file permissions]] – probably before invoking a ‘real’ <code>ls</code> command so you don’t notice it’s happened. | ||
‘real’ <code>ls</code> command so you don’t notice it’s happened. | |||
It is a good plan to have your search <code>PATH</code> lead to the commonly | It is a good plan to have your search <code>PATH</code> lead to the commonly used, trusted binaries first! | ||
used, trusted binaries first! | |||
---- | ---- | ||
{{BookChapter|17.4.2|674-675}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Security}} | {{Category|Security}} | ||
{{Category|User}} | {{Category|User}} |
Revision as of 12:43, 4 August 2019
Depends on | Security • File Permissions • System Calls • Superuser |
---|
Sometimes a user needs to do something which would not normally be permitted. One way to do this might be through a system call; another way might be via a running daemon. In each case the O.S. software can verify if the request is allowable.
Another approach – sometimes necessary – is to start a new process to perform the service. This may imply that a user starts a process posing as a different user: possibly even as the administrator. If an ordinary user was able to do this with an arbitrary process then there could be a security breach.
The Unix approach is to extend the file permissions of the process to cause the new process to run as if its owner had started it, rather than the user who did actually invoke it. This means that a file owned by root
can be executed as root
by an ordinary user. Of course the real administrator has to set up this privilege and it should only be used when the application is trusted not to do harm. The Unix approach is the setuid
bit in the file’s attributes.
A similar bit, setgid
, allows the cloning of the owner’s group ID.
Note that this feature is not confined to gaining temporary root privilege; it can be allowed by the owner of any executable file.
A Trap for the Unwary
Unix uses a search path to find a given file-name for execution; a shell will execute the first name match it finds on its $PATH. You can discover which this is from a shell: for example to find the binary used to list a directory, type which ls
.
If the path can be intercepted, a user could unwittingly execute an unintended utility. A hacker could insert a script called (say) “ls” early in your search path which you would then invoke involuntarily. This could, for example, change your file permissions – probably before invoking a ‘real’ ls
command so you don’t notice it’s happened.
It is a good plan to have your search PATH
lead to the commonly used, trusted binaries first!
Also refer to: | Operating System Concepts, 10th Edition: Chapter 17.4.2, pages 674-675 |
---|