SETUID: Difference between revisions

From COMP15212 Wiki
pc>Yuron
No edit summary
 
gravatar W81054ch [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m (1 revision imported)
 
(2 intermediate revisions by 2 users not shown)
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}}

Latest revision as of 10:03, 5 August 2019

Depends on SecurityFile PermissionsSystem CallsSuperuser

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


Articles on User
"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals