Andreas Gruenbacher wrote:
>
> I found this in the Irix B1 sources at <http://oss.sgi.com/projects/ob1>.
> The cap_enabled global variable has one of the values CAP_SYS_SUPERUSER,
> CAP_SYS_NO_SUPERUSER, CAP_SYS_DISABLED.
--
Yes, it is configurable. I think the code you are looking at is equivalent to the doc:
...
You use these two privilege mechanisms [superuser and capability] to configure your IRIX system
for one of two privilege environments:
Augmented Superuser
The augmented superuser privilege environment is a combination of the superuser-based privilege
mechanism and the capability-based privilege mechanism. In this environment, an administrator
logged in as root (user ID of 0) has unlimited, universally inherited privilege. Therefore, the
administrator must be careful when executing commands to use only known commands and processes
that are appropriate to the task at hand. Use of an untrusted command by the root user could grant
unlimited privilege to a Trojan Horse program (a program designed to usurp access rights or privilege
while performing an otherwise useful and apparently benign function).
Note that while the superuser-based privilege mechanism grants root unlimited privilege, that
privilege does not take the form of capabilities. Capability assignment and inheritance is not affected in
any way by the user ID of the process.
The augmented superuser privilege environment also employs the capability-based privilege
mechanism. This allows nonroot processes to obtain privilege through specific assignment of
inheritance of capabilities. The IRIX system does not automatically assign capabilities to users other
than root (the system administrator) and auditor (the auditor). The IRIX system does, however, assign
capabilities to certain nonadministrative commands and daemons. This allows fine control of privilege
within these commands when they are executed by a nonroot process.
The augmented superuser privilege environment most closely resembles the traditional UNIX privilege
environment. It allows administration without specific concern for capabilities and capability
inheritance. The advantage is simple administration and administrative flexibility. The disadvantage is
the relative ease with which an administrator or system programmer can make a mistake that results
in a security failure.
No Superuser
The no-superuser privilege environment contains only the capability-based privilege mechanism. In
this environment the system administrator account is still root and the auditor account is still auditor,
but root no longer derives privilege from its user ID. Instead, all privilege derives from capabilities.
The no-superuser privilege environment yields the greatest protection from administrative error and
Trojan Horse attack. It does, however, limit privilege to the set of commands authorized for
capabilities, which may not include all commands that need privilege at your site. Also, it limits
administrative flexibility by constraining administrators to commands that can inherit capabilities.
The advantage of the no-superuser privilege environment is enhanced assurance that privilege will not
be abused or usurped. The disadvantage is somewhat increased administrative complexity and
decreased administrative flexibility.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:31 EST