James Thanks for your comments. I think I should have discussed this proposal with you before.
Some answers inline. James Carlson wrote: > James Gates writes: > >> I'm sponsoring this case on behalf of Mayuresh Nirhali. Timeout is set >> for 10/22/2008. Attached is the one_pager and FOSS checklist. ARC review >> is required on account of their being configuration files in /etc and >> setuid/setgid privileged binaries. >> > > Yay! > > >> Dante is a circuit-level firewall/proxy that can be used to provide >> convenient and secure network connectivity to a wide range of hosts >> while requiring only the server Dante runs on to have external >> network connectivity. >> > > Are there follow-on projects to SOCKSify applications? > I have not heard of any, yet. This integration is part of the ongoing OSS effort. > >> Are there any setuid/setgid privileged binaries in the project? >> [X] Yes - ARC review required >> > [...] > >> >> If yes then are the setuid/setgid privileges handled by the use of >> roles? >> [ ] Yes >> [X] No - ARC review required >> > > If you're using SMF for the service, then what's the need for > setuid/setgid? > I got the answer to the second question incorrect. We are using RBAC here and the 's' bit is not going to be set for the socks server binary, so with SMF we ensure that only the privileged can run this server. > >> 3.4.3 Auditing >> (see http://opensolaris.org/os/community/arc/policies/audit-policy/ >> for details) >> (see http://opensolaris.org/os/community/arc/caselog/2003/397 for >> details) >> Does this component contain administrative or security enforcing >> software? >> [ ] Yes - ARC review required >> [X] No - continue to next section (section 3.4.4) >> > > Is that answer right? The SOCKS server *does* have a facility to > authenticate users and enforce security, doesn't it? I don't think > this has auditing capabilities. > It isnt. You are right, it does not have auditing capabilities. I will make the changes in the proposal. > >> 3.4.4 Authentication >> (see http://opensolaris.org/os/community/arc/policies/PAM/) >> Do the components contain any authentication code? >> [ ] Yes >> [X] No - continue to next section (section 3.4.5) >> > > The normal Dante server does. You set it up with the "method:" > keyword. > Yes. I am currently looking into answers to the following questions and will send the updated proposal soon. > >> 3.4.5 Passwords >> (see >> http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and >> >> http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for >> details) >> Do any of the components for the project deal with passwords? >> [ ] Yes >> [X] No - continue to next section (section 3.4.6) >> > > Yes; both client and server can use passwords and user names. > yes, thanks! again, I need to find answers to the following questions and will update the proposal. > >> Do network services for the project make decisions based upon user, >> host or >> service identities? >> [ ] Yes - explain below >> [X] No >> [ ] N/A >> > > Yes, they can do this. > Thanks, will update this. > >> Do the components make use of secret information during authentication >> and/or >> authorization? >> [ ] Yes - explain below >> [X] No >> [ ] N/A >> > > Yes. > Thanks, will update this as well. > >> | 1 | libdsocks.so | Unstable/Uncommitted | SOCKS daemon >> library | >> | >> |---------------------+--------------------------------------------------| >> | 2 | libsocks.so | Unstable/Uncommitted | SOCKS library >> | >> > > Given the age and stability of this project, and the way in which > SOCKSified applications depend on them, I don't think the above is > right. > > Plus, "Unstable" isn't a commitment level. > > I suspect that libdsocks.so is actually Project Private (nothing > outside of Dante should use it), and that libsocks.so is a Committed > interface (it's not going to change incompatibly; it's set by the BSD > sockets interface). > > Agree here. will do. >> Dante is a third party Socks server and client implementation. The >> current version (1.1.19) is stable and it was released in >> January 2006. Since then, there has been no releases of this product. >> > > That conflicts with the interface stability. If it's stable, then > let's make it stable for our customers as well. > > >> SMF service for Dante SOCKS server will be added under network category >> as >> network/sockd. The package will add the manifest file and SMF method as >> below, >> > > Nit: please use network/socks rather than network/sockd. We're trying > to avoid 'd' for 'daemon' in the names of SMF FMRIs. > Sure. I was caught up with some urgent escalation for last couple of days. I will get the details and make the necessary changes to the proposal next week. Thanks again Mayuresh
