Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
privileges(5)							 privileges(5)

       privileges - process privilege model

       Solaris	software  implements  a	 set  of privileges that provide fine-
       grained control over the	actions	of processes. The possession of	a cer-
       tain privilege allows a process to perform a specific set of restricted

       The change to a primarily privilege-based security model	in the Solaris
       operating  system gives developers an opportunity to restrict processes
       to those	privileged operations actually needed instead of  all  (super-
       user)  or  no privileges	(non-zero UIDs). Additionally, a set of	previ-
       ously unrestricted operations now requires a  privilege;	 these	privi-
       leges are dubbed	the "basic" privileges and are by default given	to all

       Taken together, all defined privileges with the exception of  the  "ba-
       sic"  privileges	 compose  the set of privileges	that are traditionally
       associated with the root	user. The "basic" privileges are  "privileges"
       unprivileged processes were accustomed to having.

       The defined privileges are:


	   Allows a process to request reliable	delivery of events to an event
	   endpoint. Allows a process to include events	in the critical	 event
	   set	term  of  a template which could be generated in volume	by the


	   Allows a process to observe contract	events generated by  contracts
	   created  and	owned by users other than the process's	effective user
	   ID. Allows a	process	to open	contract event endpoints belonging  to
	   contracts  created  and owned by users other	than the process's ef-
	   fective user	ID.


	   Allow a process to access per-CPU hardware performance counters.


	   Allow DTrace	process-level  tracing.	 Allow	process-level  tracing
	   probes  to be placed	and enabled in processes to which the user has


	   Allow DTrace	user-level tracing. Allow use of the syscall and  pro-
	   file	 DTrace	 providers  to examine processes to which the user has


	   Allow DTrace	kernel-level tracing.


	   Allow a process to change a file's owner user ID. Allow  a  process
	   to  change a	file's group ID	to one other than the process's	effec-
	   tive	group ID or one	of the process's supplemental group IDs.


	   Allow a process to give away	its files. A process with this	privi-
	   lege	will run as if {_POSIX_CHOWN_RESTRICTED} is not	in effect.


	   Allow a process to execute an executable file whose permission bits
	   or ACL would	otherwise disallow the process execute permission.


	   Allow a process to read a file or directory whose  permission  bits
	   or ACL would	otherwise disallow the process read permission.


	   Allow  a process to search a	directory whose	permission bits	or ACL
	   would not otherwise allow the process search	permission.


	   Allow a process to write a file or directory	whose permission  bits
	   or  ACL  do	not allow the process write permission.	All privileges
	   are required	to write files owned by	UID 0 in the absence of	an ef-
	   fective UID of 0.


	   Allow a process to create hardlinks to files	owned by a UID differ-
	   ent from the	process's effective UID.


	   Allow a process that	is not the owner of  a	file  to  modify  that
	   file's  access  and modification times. Allow a process that	is not
	   the owner of	a directory to modify that directory's access and mod-
	   ification times. Allow a process that is not	the owner of a file or
	   directory to	remove or rename a file	or directory whose parent  di-
	   rectory has the "save text image after execution" (sticky) bit set.
	   Allow a process that	is not the owner of a file to mount  a	namefs
	   upon	 that file. Allow a process that is not	the owner of a file or
	   directory to	modify that file's or directory's permission  bits  or


	   Allow  a  process  to  change the ownership of a file or write to a
	   file	without	the set-user-ID	and set-group-ID bits  being  cleared.
	   Allow  a process to set the set-group-ID bit	on a file or directory
	   whose group is not the process'  effective  group  or  one  of  the
	   process'  supplemental groups. Allow	a process to set the set-user-
	   ID bit on a file  with  different  ownership	 in  the  presence  of
	   PRIV_FILE_OWNER.  Additional	 restrictions  apply  when creating or
	   modifying a setuid 0	file.


	   Allow a process to read a System V  IPC  Message  Queue,  Semaphore
	   Set,	 or Shared Memory Segment whose	permission bits	would not oth-
	   erwise allow	the process read permission.


	   Allow a process to write a System V IPC  Message  Queue,  Semaphore
	   Set,	 or Shared Memory Segment whose	permission bits	would not oth-
	   erwise allow	the process write permission.


	   Allow a process that	is not the owner of a  System  V  IPC  Message
	   Queue,  Semaphore  Set,  or Shared Memory Segment to	remove,	change
	   ownership of, or change permission bits of the Message Queue, Sema-
	   phore Set, or Shared	Memory Segment.


	   Allow a process to send and receive ICMP packets.


	   Allow  a process to bind to a privileged port number. The privilege
	   port	numbers	are 1-1023 (the	traditional UNIX privileged ports)  as
	   well	 as  those ports marked	as "udp/tcp_extra_priv_ports" with the
	   exception of	the ports reserved for use by NFS.


	   Allow a process to have direct access to the	network	layer.


	   Allow a process to change its root directory.


	   Allow a process to use high resolution timers.


	   Allow a process to generate audit records. Allow a process  to  get
	   its own audit pre-selection information.


	   Allow a process to call execve(2).


	   Allow a process to call fork(2), fork1(2), or vfork(2).


	   Allow a process to examine the status of processes other than those
	   to which it can send	signals. Processes  that  cannot  be  examined
	   cannot be seen in /proc and appear not to exist.


	   Allow a process to lock pages in physical memory.


	   Allow  a process to send signals to other processes and inspect and
	   modify the process state in other processes,	regardless  of	owner-
	   ship.  When	modifying another process, additional restrictions ap-
	   ply:	the effective privilege	set of the attaching process must be a
	   superset  of	the target process's effective,	permitted, and inheri-
	   table sets; the limit set must be a superset	of the target's	 limit
	   set;	 if the	target process has any UID set to 0 all	privilege must
	   be asserted unless the effective UID	is 0. Allow a process to  bind
	   arbitrary processes to CPUs.


	   Allow  a  process  to elevate its priority above its	current	level.
	   Allow a process to change its scheduling class  to  any  scheduling
	   class, including the	RT class.


	   Allow a process to send signals or trace processes outside its ses-


	   Allow a process to set its UIDs at will, assuming  UID  0  requires
	   all privileges to be	asserted.


	   Allow a process to assign a new task	ID to the calling process.


	   Allow  a  process  to  trace	 or send signals to processes in other
	   zones. See zones(5).


	   Allow a process to enable and disable and manage accounting through


	   Allow a process to perform system administration tasks such as set-
	   ting	node and domain	name and specifying coreadm(1M)	 and  nscd(1M)


	   Allow a process to start the	(kernel) audit daemon. Allow a process
	   to view and set audit state (audit user ID, audit terminal ID,  au-
	   dit sessions	ID, audit pre-selection	mask). Allow a process to turn
	   off and on auditing.	Allow a	process	to configure the audit parame-
	   ters	 (cache	 and  queue sizes, event to class mappings, and	policy


	   Allow a process to perform various system configuration tasks.  Al-
	   low filesystem-specific administrative procedures, such as filesys-
	   tem configuration ioctls, quota calls,  creation  and  deletion  of
	   snapshots, and manipulating the PCFS	bootsector.


	   Allow  a process to create device special files. Allow a process to
	   successfully	 call  a  kernel  module   that	  calls	  the	kernel
	   drv_priv(9F)	 function to check for allowed access. Allow a process
	   to open the real console device directly. Allow a process  to  open
	   devices that	have been exclusively opened.


	   Allow  a  process  to  increase  the	size of	a System V IPC Message
	   Queue buffer.


	   Allow a process to unlink and link directories.


	   Allow a process to mount and	unmount	filesystems that would	other-
	   wise	be restricted (that is,	most filesystems except	namefs). Allow
	   a process to	add and	remove swap devices.


	   Allow a process to configure	 a  system's  network  interfaces  and
	   routes.  Allow a process to configure network parameters using ndd.
	   Allow a process access to otherwise	restricted  information	 using


	   Allow  a  process to	provide	NFS service: start NFS kernel threads,
	   perform NFS locking operations, bind	to NFS reserved	 ports:	 ports
	   2049	(nfs) and port 4045 (lockd).


	   Allow a process to create and delete	processor sets,	assign CPUs to
	   processor sets and override the  PSET_NOESCAPE  property.  Allow  a
	   process  to change the operational status of	CPUs in	the system us-
	   ing p_online(2). Allow a process to	configure  filesystem  quotas.
	   Allow  a  process to	configure resource pools and bind processes to


	   Allow a process to exceed the resource  limits  imposed  on	it  by
	   setrlimit(2)	and setrctl(2).


	   Allow  a process to successfully call a third party loadable	module
	   that	calls the kernel suser() function to check for allowed access.
	   This	privilege exists only for third	party loadable module compati-
	   bility and is not used by Solaris proper.


	   Allow a process to manipulate system	time using any of  the	appro-
	   priate system calls:	stime(2), adjtime(2), and ntp_adjtime(2).

       Of  the	privileges  listed  above,  the	privileges PRIV_FILE_LINK_ANY,
       are considered "basic" privileges. These	are privileges that used to be
       always available	to unprivileged	processes. By default, processes still
       have the	basic privileges.

       The  privileges	PRIV_PROC_SETID	and PRIV_PROC_AUDIT must be present in
       the Limit set (see below) of a process in order for set-uid root	 execs
       to  be  successful,  that  is, get an effective UID of 0	and additional

       The privilege implementation in Solaris extends the process  credential
       with four privilege sets:

       I, the inheritable set

	   The privileges inherited on exec.

       P, the permitted	set

	   The maximum set of privileges for the process.

       E, the effective	set

	   The privileges currently in effect.

       L, the limit set

	   The	upper  bound of	the privileges a process and its offspring can
	   obtain. Changes to L	take effect on the next	exec.

       The sets	I, P and E are typically identical to the basic	set of	privi-
       leges  for  unprivileged	processes. The limit set is typically the full
       set of privileges.

       Each process has	a Privilege Awareness State (PAS) that	can  take  the
       value  PA  (privilege-aware)  and  NPA  (not-PA). PAS is	a transitional
       mechanism that allows a choice between full compatibility with the  old
       superuser model and completely ignoring the effective UID.

       To  facilitate the discussion, we introduce the notion of "observed ef-
       fective set" (oE) and "observed permitted set" (oP) and the implementa-
       tion sets iE and	iP.

       A process becomes privilege-aware either	by manipulating	the effective,
       permitted, or limit privilege sets  through  setppriv(2)	 or  by	 using
       setpflags(2).  In  all cases, oE	and oP are invariant in	the process of
       becoming	privilege-aware. In the	process	of  becoming  privilege-aware,
       the following assignments take place:

       iE = oE
       iP = oP

       When  a	process	 is privilege-aware, oE	and oP are invariant under UID
       changes.	When a process is not privilege-aware, oE and oP are  observed
       as follows:

       oE = euid == 0 ?	L : iE
       oP = (euid == 0 || ruid == 0 || suid == 0) ? L :	iP

       When  a	non-privilege-aware  process has an effective UID of 0,	it can
       exercise	the privileges contained in its	limit set, the upper bound  of
       its privileges. If a non-privilege-aware	process	has any	of the UIDs 0,
       it will appear to be capable of potentially exercising  all  privileges
       in L.

       It is possible for a process to return to the non-privilege aware state
       using setpflags(). The kernel will  always  attempt  this  on  exec(2).
       This operation is permitted only	if the following conditions are	met:

	 o  If any of the UIDs is equal	to 0, P	must be	equal to L.

	 o  If the effective UID is equal to 0,	E must be equal	to L.

       When  a process gives up	privilege awareness, the following assignments
       take place:

       if (euid	== 0) iE = L & I
       if (any uid == 0) iP = L	& I

       The privileges that do not have a UID of	0 will be the inheritable  set
       of the process restricted by the	limit set.

       Only privileges in the process's	(observed) effective privilege set al-
       low the process to perform restricted operations. A process can use any
       of  the	privilege  manipulation	 functions to add or remove privileges
       from the	privilege sets.	Privileges can be removed always. Only	privi-
       leges  found in the permitted set can be	added to the effective and in-
       heritable set. The limit	set cannot grow. The inheritable  set  can  be
       larger than the permitted set.

       When a process performs an exec(2), the kernel will first try to	relin-
       quish privilege awareness before	making	the  following	privilege  set

       E' = P' = I' = L	& I
       L is unchanged

       If a process has	not manipulated	its privileges,	the privilege sets ef-
       fectively remain	the same, as E,	P and I	are already identical.

       The limit set is	enforced at exec time.

       To run a	non-privilege-aware application	in a backward-compatible  man-
       ner, a privilege-aware application should start the non-privilege-aware
       application with	I=basic.

       For most	privileges, absence of the privilege simply results in a fail-
       ure.  In	 some  instances,  the absense of a privilege can cause	system
       calls to	behave differently. In other instances,	the removal of a priv-
       ilege  can force	a set-uid application to seriously malfunction.	Privi-
       leges of	this type are considered "unsafe". When	a process  is  lacking
       any  of	the  unsafe privileges from its	limit set, the system will not
       honor the set-uid bit of	set-uid	root applications. The	following  un-
       safe  privileges	 have  been  identified:  proc_setid, sys_resource and

   Privilege Escalation
       In certain circumstances, a single privilege could lead	to  a  process
       gaining	one  or	 more  additional  privileges that were	not explicitly
       granted to that process.	To prevent such	an escalation  of  privileges,
       the  security  policy  will require explicit permission for those addi-
       tional privileges.

       Common examples of escalation are those mechanisms that allow modifica-
       tion of system resources	through	"raw'' interfaces; for example,	chang-
       ing kernel data structures through /dev/kmem or changing	files  through
       /dev/dsk/*.  Escalation	also  occurs when a process controls processes
       with more privileges than the controlling process. A  special  case  of
       this  is	 manipulating  or creating objects owned by UID	0 or trying to
       obtain UID 0 using setuid(2). The special treatment of UID 0 is	needed
       because the UID 0 owns all system configuration files and ordinary file
       protection mechanisms allow processes with UID 0	to modify  the	system
       configuration.  With  appropriate  file	modifications, a given process
       running with an effective UID of	0 can gain all privileges.

       In situations where a process might obtain UID 0, the  security	policy
       requires	 additional privileges,	up to the full set of privileges. Such
       restrictions could be relaxed or	removed	at  such  time	as  additional
       mechanisms  for	protection of system files became available. There are
       no such mechanisms in the current Solaris release.

       The use of UID 0	processes should be limited as much as possible.  They
       should be replaced with programs	running	under a	different UID but with
       exactly the privileges they need.

       Daemons	that  never  need  to  exec  subprocesses  should  remove  the
       PRIV_PROC_EXEC privilege	from their permitted and limit sets.

   Privilege Debugging
       When  a system call fails with a	permission error, it is	not always im-
       mediately obvious what caused the problem. To debug such	a problem, you
       can  use	a tool called privilege	debugging. When	privilege debugging is
       enabled for a process, the kernel reports  missing  privileges  on  the
       controlling  terminal  of  the process. (Enable debugging for a process
       with the	-D option of ppriv(1).)	Additionally,  the  administrator  can
       enable  system-wide  privilege debugging	by setting the system(4) vari-
       able priv_debug using:

       set priv_debug =	1

       On a running system, you	can use	mdb(1) to change this variable.

       mdb(1),	ppriv(1),  add_drv(1M),	 ifconfig(1M),	lockd(1M),   nfsd(1M),
       rem_drv(1M), update_drv(1M), Intro(2), access(2), acct(2), acl(2), adj-
       time(2),	audit(2), auditon(2),  auditsvc(2),  chmod(2),	chown(2),  ch-
       root(2),	   creat(2),   exec(2),	  fcntl(2),   fork(2),	 fpathconf(2),
       getacct(2), getpflags(2),  getppriv(2),	getsid(2),  kill(2),  link(2),
       memcntl(2),  mknod(2),  mount(2),  msgctl(2),  nice(2), ntp_adjtime(2),
       open(2),	p_online(2), priocntl(2),  priocntlset(2),  processor_bind(2),
       pset_bind(2),  pset_create(2),  readlink(2),  resolvepath(2), rmdir(2),
       semctl(2), setauid(2), setegid(2), seteuid(2), setgid(2), setgroups(2),
       setpflags(2),  setppriv(2), setrctl(2), setregid(2), setreuid(2), setr-
       limit(2),  settaskid(2),	 setuid(2),  shmctl(2),	 shmget(2),  shmop(2),
       sigsend(2), stat(2), statvfs(2),	stime(2), swapctl(2), sysinfo(2), uad-
       min(2),	 ulimit(2),   umount(2),   unlink(2),	utime(2),   utimes(2),
       bind(3SOCKET),	 door_ucred(3DOOR),   priv_addset(3C),	 priv_set(3C),
       priv_getbyname(3C),	 priv_getbynum(3C),	  priv_set_to_str(3C),
       priv_str_to_set(3C),  socket(3SOCKET), t_bind(3NSL), timer_create(3RT),
       ucred_get(3C),	exec_attr(4),	proc(4),   system(4),	 user_attr(4),
       ddi_cred(9F),	drv_priv(9F),	priv_getbyname(9F),   priv_policy(9F),
       priv_policy_choice(9F), priv_policy_only(9F)

				  19 Jul 2004			 privileges(5)


Want to link to this manual page? Use this URL:

home | help