Alan M Wright wrote: > On 03/23/09 02:38, Darren J Moffat wrote: >> Jordan Brown wrote: >>> In order to configure properties using sharectl(1M), a user must >>> be the superuser or assume an equivalent role to obtain the >>> solaris.smf.value.smb and solaris.smf.manage.smb RBAC >>> authorizations, or use the SMB Management RBAC profile, which >>> is part of the File System Management profile. >> >> This case makes that authorisation equivalent to handing out the list >> of privileges below. I'm not sure that is a safe thing to do. > > The purpose is to allow the root user to do anything that > would be possible if root was to login and run the command.
We try very hard in Solaris not to think and code this way anymore. That is why we have privileges and authoriations and all the other tools from RBAC. If the intent is actually that only root should be able to do this then the ability to set it up shouldn't be controlled via a solaris.smf hierarchy RBAC authorisation. The 'SMB Management RBAC profile' is probably suitable but the specific solaris.smb.*.smb auths probably aren't. >> I need some more time to thing about this and see if there is a safer >> way to achieve this. I have some ideas (that won't be difficult to >> implement) I just need to think through them a bit more first. > > Okay. > >>> Additional privileges are required to allow the smbd process to >>> fork a child process and execute the commands. The privileges >>> will be enabled in the effective set and inheritable set when >>> needed for command execution. Otherwise, they will be disabled. >>> >>> The following privileges are enabled for the exec'd process: >>> PRIV_FILE_CHOWN, PRIV_FILE_CHOWN_SELF, PRIV_FILE_DAC_EXECUTE, >>> PRIV_FILE_DAC_READ, PRIV_FILE_DAC_SEARCH, PRIV_FILE_DAC_WRITE, >>> PRIV_FILE_LINK_ANY, PRIV_FILE_OWNER, PRIV_FILE_SETID, >>> PRIV_PROC_EXEC, PRIV_PROC_FORK, PRIV_PROC_INFO, PRIV_PROC_OWNER, >>> PRIV_PROC_SESSION, PRIV_PROC_SETID, PRIV_SYS_CONFIG, >>> PRIV_SYS_LINKDIR, and PRIV_SYS_MOUNT. >> >> Where did this list of privileges come from (other than those in the >> basic set)? Why this list and in particular why the very powerful >> sys_config ? > > >> Is it just because that is what smbd is running with ? I want the >> case to give the reason why this set of privileges rather than some >> other set is the correct and useful set. > > smbd doesn't need these privileges, this is only to support > the automated execution of the command. Then sys_config is highly inappropriate in my opinion, I can also imagine cases where that list of privileges isn't actually sufficient - since it won't be possible to change any root owned files with just that list. This should either run as root with all privs - and thus required root with all privs to configure it (not an RBAC authorisation likely to be given out for lower impact things). This is basically how dhcpagent does it. Or - and this is my preferred option - there should be a requirement that the commands be listed in a specific RBAC exec_attr(4) profile and that smbd 'pfexec' them and by default they only run with basic privs (unless the exec_attr(4) profile gives them more. We can work the details of how to do this offline with the security team. The name of the RBAC profile would be a Committed interface and it would likely be empty by default. -- Darren J Moffat
