[SCIM] Re: [Uim] Design philosophy and strength of uim

Hideki Hiura hiura at openi18n.org
Wed Jun 30 04:22:17 PDT 2004


> From: YamaKen <yamaken at bp.iij4u.or.jp>
> - whether UNIX domain socket MUST be used or SHOULD be used
> - whether INET domain socket MUST not be used or SHOULD not be used
> - permission issues of server process
> - possible vulnerability due to design of the server
> - resource isolation between input methods (such as memory space)
> - etc, etc...

I would recommend you to add the rationale behind each such conditions
so that it would be clear for everybody why those conditions should
only be applied to here while you are using bunch of INET domain
sockets on your machine regularly for other services, such as
Web/Mail/news/ssh/ftp/telnet etc... and why it is OK to run UNIX
deamons with privilege on the same host you enforce such conditions to
particular components?

Let's exercise the same logic with an popular example to see things
clearly.
Soppose your listings above alone is as reasonable as it can be applied
generally, for example, I am afraid you couldn't even send your mail
[200406301045.i5UAjTFw001681 at mbox01.iij4u.or.jp] as those whom extremely
concerns about security unless your conditions are just inaccurate but
not double standard.

Here is the hypothetical questionare in this senario:

Did you use INET socket to send your mail? Was its transport
encripted?  Did you authenticate SMTP server before sending it?  Did
the SMTP server you connected authenticate your MUA/MTA? Did you
authenticate your DNS server? Did you veryfy the answer your DNS
server replied?  Did you secure the entire route from your MUA/MTA to
the destination?  Did you authenticate the destination host?  Did you
get assurance on the all relaying MTAs(if any) authenticate the next
relaying MTA?

--
hiura@{freestandards.org,OpenI18N.org,li18nux.org,unicode.org,sun.com} 
Chair, OpenI18N.org/The Free Standards Group          http://www.OpenI18N.org
Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA   eFAX: 509-693-8356



More information about the scim mailing list