A Preliminary Study on the Profile permission Control System of Solaris

Article Title: A Preliminary Study on the Profile permission Control System of Solaris. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Commands such as pfexec of Solaris are strange. I didn't understand how to use them. I checked that it was a new permission management system that could control user permissions in a more fine-grained manner.
　　
One of the main reasons for its development is the use of this system, you can cancel the OS's built-in command to set the suid bit.
　　
For example, if you want the test user to execute/usr/bin/sh and the permission is uid = 0 euid = 0, you can use the following control policy:
Add the following in/etc/user_attr:
Test: type = normal; auths = solaris. *, solaris. grant; profiles = ATestProfile
　　
Add the following in/etc/security/exec_attr:
ATestProfile: suser: cmd:/usr/bin/sh: uid = 0; euid = 0
　　
The two modifications mean that the Profile of user test is ATestProfile, and the user whose Profile is ATestProfile executes the/usr/bin/sh command using suid (suser is the meaning ), and uid = 0 euid = 0.
Here, commands such as/usr/bin/sh can use wildcards, such *
　　
In this way, we can use the following:
Bash-2.03 $ id
Uid = 1022 (test) gid = 1 (other)
Bash-2.03 $ pfexec/usr/bin/sh
# Id
Uid = 0 (root) gid = 1 (other)
#
　　
This controls the permissions of the test user when executing the/usr/bin/sh program.
　　
This mechanism is very flexible.
　　
However, the default Profile permission system has some problems, such:
Bash-2.03 $ cat exec_attr
All: suser: cmd :::*:
Audit Control: suser: cmd:/etc/init. d/audit: euid = 0; egid = 3
Audit Control: suser: cmd:/etc/security/bsmconv: uid = 0
Audit Control: suser: cmd:/etc/security/bsmunconv: uid = 0
Audit Control: suser: cmd:/usr/sbin/audit: euid = 0
Audit Control: suser: cmd:/usr/sbin/auditconfig: euid = 0
Audit Control: suser: cmd:/usr/sbin/auditd: uid = 0
Audit Review: suser: cmd:/usr/sbin/auditreduce: euid = 0
Audit Review: suser: cmd:/usr/sbin/praudit: euid = 0
Audit Review: suser: cmd:/usr/sbin/auditstat: euid = 0
　　
If the Profile is Audit Control, users can use uid = 0 to execute commands such as/etc/security/bsmconv. However, these commands are shell programs that use a large number of commands in relative paths:
....
PROG = bsmconv
STARTUP =/etc/security/audit_startup
DEVALLOC =/etc/security/device_allocate
DEVMAPS =/etc/security/device_maps
TEXTDOMAIN = "SUNW_OST_OSCMD"
Export TEXTDOMAIN
　　
Permission ()
{
WHO = 'id | cut-f1-d "" '# <----------- here
If [! "$ WHO" = "uid = 0 (root)"]
Then
Form = 'gettext "% s: ERROR: you must be super-user to run this script ."'
Printf "$ {form} \ n" $ PROG
Exit 1
Fi
　　
.........
　　
If the Profile of a registered user is Audit Control, the user can obtain the root permission through this security vulnerability.
　　
　　
Fortunately, the system has only one row in user_attr by default,
Root: type = normal; auths = solaris. *, solaris. grant; profiles = All
　　
As a system administrator, the Profile system provides a lot of convenience for the granularity of Management permissions.
　　
All of the above are tested on Solaris 8.
Solaris9 still uses this system.