I'm just getting back to this from the out of band LSARC
review that suggested the case was more appropriate for
PSARC.
> [2] Dante server uses Solaris PAM for authentication which requires the
> privileged user to be 'root'. Hence, the privileged user (i.e. root)
> will have all the privileges even when not all of them are required.
> This is not the current recommended practice, but is this acceptable at
> all?
A lot of the discussion has centered around here. I suppose
the project team could just not support username/password
authentication. If I read the Socks 5 RFC correctly,
username/password is a "should." I don't know if that would be
acceptable to the customer base or not.
That said, one of the exported interfaces for all PAM applications
is the service name. Perhaps I missed it in the exported interfaces.
Stability should likely be no lower than Uncommitted. The service
name is important and needs to be documented on the socksd man
page so admins can configure pam.conf accordingly. Since the
protocol is explicitly username followed by password, the service's
PAM stack should be specified. You also probably want to specify
the account stack. I'd expect to see this in the sockd(1m) man
page. It may wish to also say something about pam_servicename
in sockd.conf(4) and how that all applies.
Furthermore, a project could create a PAM service module just
to handle socks username/password authentication (and account
management) that didn't need to be tied to the hosts passwd(4) and
shadow(4) databases -- that may require no privilege.
To do authentication and account management as appears in
sockd:auth_pam.c should only require euid 0, privs = none, or
euid = uid != 0, privs = file_dac_read.
IMO, the PAM code in auth_pam.c exhibits confusion. I don't
believe inet_ntoa() is a valid PAM_RHOST value. The project team
should take Joep up on his offer to help, or any of the other folk
on pam-core at sun.com.
I believe the real (PAM) security issue is exposing the system users
accounts to the internet. Safe programming (and running uid != 0,
privs - file_dac_read) can ensure that whatever inputs are stuffed
over the protocol do not meet with privilege escalation. However
this does leave the system open to username and password probing
attacks that are likely not audited.
The project team may wish considering adding Solaris Audit calls
to mitigate this exposure.
A couple nits:
> /usr/man/man4/sockd.conf.5
> /usr/man/man4/socks.conf.5
These should be sockd.conf.4 and socks.conf.5
> 4.7. Admin/Config Impact:
>
> The package will also provide template of configuration files
> for both server and client. The templates for these configureation
> files are attached.
>
> /etc/sockd.conf
> /etc/socks.conf
These samples don't seem to be in the case directory, or mail log.
My download doesn't seem contain sample files either.
Gary..
