"The Linux Gazette...making Linux just a little more fun!"

PAM applications running as root (Was Re: WebTrends Enterprise Reporting Server)

From Darren Moffat on Sun, 17 Oct 1999

You can run the server as root or as some other user. In order to use PAM (Pluggable Authentication Module) it has to run as root.

A general comment about PAM rather than this specific problem.

It is NOT a requirement of the PAM framework that application be running as root. There are two cases though that make login type applications need to run as root.

1) The password is stored in /etc/shadow which only root can read

If the password was in NIS/NIS+/LDAP then the authentication could succeed are an ordinary user.

Actually it should be possible for /etc/shadow to be group readable and associated with a "shadow" or "auth" group. Then SGID programs could authenticate against it.

A different level of access could be required to modify it (that would presumably be reserved for root, since the ability to modify the /etc/shadow and /etc/passwd files on those systems that are configured to honor local files will consitute root access in any event).

2) the login application needs to make setuid/setgid calls this

usually happens in the application after PAM authentication has been completed and is thus nothing to do with PAM.

If the OS has privileges/capabilities then the application would assert PROC_SETID/CAP_SETID instead of being root to make the setuid/setgid calls.

Linux 2.2 has privs implemented in the kernel. There is, as yet, no filesystem system support for storing the priv. bitfield metadata. So, anyone wishing to "capify" the Linux authentication system would have to do so through wrappers.

I'm personally disappointed by the lack of progress in this field.

It seems that we should have at least attained the ability to emulate BSD securelevel (wrapper or patches to init(8)) and to limit certain well-defined daemons (like xntpd, routed/gated, syslogd) to their specific priv sets (set time, modify routing tables, bind to priv ports).

We should be able to use the immutable and append-only filesystem attributes, the read-only mount option and the chroot() system calls as rootsafe security features and we should be able to audit many (traditionally root run processes) daemons and SUID utilities in terms of their "most damage from subversion."

Well, it looks like I have to do some coding on this myself. (One look at my code should scare some others into doing it right!)

BTW: Does Solaris implement POSIX.1e "capabilities" (privs)? How about HP-UP, AIX, et al? Are those in the mainstream OS APIs or are they only available in "Trusted" (MLS/CMW) versions?

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by Heather Stern of Starshine Technical Services, https://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57