On Fri, Jul 30, 2010 at 04:59:57AM -0700, Mike DeMarco wrote: > Build 134: 1) Could anyone please explain why root has been converted > to a role. I would venture a guess that someone somewhere believes > that it is more secure to run root as a role. The whole "if root can > not log directly into the box than someone can not crack the root > password. Well I agree that root should not be allowed to login from > the net but locking a root account out of console login relies on the > user account always being valid. and how much harder is it to hack the > user then move on to root, especially when the root password is the > same as the users. Having root as a role is causing me many problems > and I am wondering if others are in agreement or disagreement with > this practice?
I'm in total agreement from a security aspect (recall that OpenSolaris's roots are in the enterprise server world and not wide open desktop land). I would ask you why root shouldn't be a role? Hopefully the answer won't involve convenience. > 2) I have noticed that when sound-juicer is started by a non-root > user the process runs as root and writes its files as root, WOW what > a huge security hole this is. To have a non-privileged user able to > start and control an application that writes files as root with root > privilege to any filesystem! As others have written, this sounds like a setuid root program of which there are a number. Really, all those programs should be running with only the specific privileges necessary to allow them to function properly but this will take time to make the necessary modifications. And really, security is typically enhanced by minimizing the packages installed to just those needed. As an example of using specific privileges, I noticed that when installing gpg, the install process was modifying the permissions on gpg to make it setuid root so that it could allocate "locked" memory which prevents it from being swapped to disk in low memory situations. On OpenSolaris using setuid root just for this is unnecessary when one can just assign the proc_lock_memory privilege to gpg. I did this by: 1. Renaming the gpg binary to /usr/local/bin/gpg.bin 2. Adding these lines to /etc/security/exec_attr: exec_attr:Basic Solaris User:solaris:cmd:::/usr/local/bin/gpg.bin:privs=proc_lock_memory exec_attr:Primary Administrator:solaris:cmd:::/usr/local/bin/gpg.bin:privs=proc_lock_memory Note that I added the Primary Administrator stanza because I sometimes need to run gpg as a user with that profile. 3. Creating a shell script called /usr/local/bin/gpg which is: #!/bin/ksh -p unset LD_PRELOAD LD_LIBRARY_PATH # To set proper priv. to lock memory pfexec /usr/local/bin/gpg.bin "$@" ################ end ############ At this point I can run gpg and it can allocate locked/pinned memory but has not other additional privileges except for those granted a basic user. -- Will Fiveash Oracle Note my new work e-mail address: [email protected] http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/ _______________________________________________ opensolaris-discuss mailing list [email protected]
