On 06/15/09 15:26, Tom Whitten wrote: > Sangeeta Misra writes: > >> On 06/15/09 11:46, Tom Whitten wrote: >> >>> Sangeeta Misra writes: >>> >>> >>>> Folks, >>>> Currently ilbd daemon runs as "root" and uses SCF to store persistent >>>> configuration. ILB's rules, servergroups and healthcheck objects are >>>> represented as property groups in SCF. Note that we use the property >>>> group type SCF_GROUP_APPLICATION. >>>> >>>> >>>> >>> [SNIP] >>> >>> >>>> Question 1 >>>> =========== >>>> I assume in order to authorize ilbd daemon to successfully call the the >>>> scf_* functions to create/modify /delete/retrieve the configuration >>>> to/from scf framework, all I need to do is add this to >>>> usr/src/lib/libsecdb/user_attr.txt : >>>> >>>> >>> I'll let Gary comment on modifications to >>> usr/src/lib/libsecdb/user_attr.txt. >>> >>> >>> >>>> daemon::::auths=solaris.smf.manage.ilb,solaris.smf.modify ( or should >>>> this be solaris.smf.modify.application?) >>>> >>>> >>> >>> >> Notice that currently user_attr has this: >> dladm::::auths=solaris.smf.manage.wpa,solaris.smf.modify >> >> So a process running as "dladm" also runs the same risk. >> >> At this point I am thinking I should EITHER run ilbd as "root" ( with no >> new entry in user_attr) OR with a new uid "netadm" ( this will be a uid >> that all networking projects like NWAM, Brussels, ILB etc can use) and >> have this entry in user_attr.txt: >> >> >> netadm::::auths=solaris.smf.manage.ilb,solaris.smf.modify >> >> I am waiting for Gary to let me know what is the best solution. >> >> Sangeeta >> > > Certainly, Gary has a lot better understanding of the security issues than > I do. > > I'd still prefer to see you use solars.smf.modify.application instead of > solaris.smf.modify. Have you encountered a situation where > solars.smf.modify.application is not sufficient? > > tom > Let me try to run the entire ILB testsuite with " solaris.smf.modify.application " and see if I come across a problem.
Sangeeta -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20090615/c0d36a76/attachment.html>