Re: [Gnumed-devel] GNUmed options for security (authentication) including kerberos

[syan tan]

On Fri, 2006-12-15 at 09:26 -0800, J Busser wrote:
> I was looking over some wiki pages and came across
> 
>       http://salaam.homeunix.com/bin/view/Gnumed/ 
> DebianKerberosLDAPBindGnumedWalkthrough
> 
> Am I correct that a browser based client (like Oscar) --- if required  
> to use https --- avoids interception (in the clear) of the user's id  
> and password at any point along the network?
> 
> Am I correct to think that when one accesses a GNUmed server that was  
> set up following the basic installation procedures, there is no  
> protection against such interception, unless extra measures (like  
> kerberization of the server as per Syan's notes) are taken?
> 
> If skipping this step or equivalent could be considered poor practice  
> (poor protection of access to patient data) then must we make some  
> reference to this in the installation notes?
> 
> Related questions:
> 
> - are there any extra dependencies for client machines to access  
> kerberized GNUmed or do the basic installations of Linux distros and  
> Windows include support for kerberos so the user would need set up  
> nothing extra on the client machine(s)?
> 
> - when adding a new office worker or doctor into kerberized GNUmed  
> would each new person somehow have to be separately registered with  
> kerberos? Would this require user maintenance of a public and private  
> key separate from their GNUmed userid & password?
> 
> - though some recommend the kerberos server run no other processes  
> would people feel it is reasonable to run postgres and to serve  
> GNUmed on the same server? Are there additional process that people  
> feel should run on the same server or on a different machine, for  
> example the fetching of results and the handling of email...  
> different machine??? Would running different virtual machines on the  
> same physical machine be a good way to achieve what is desirable,  
> supposing data could be "pushed" across the machines as required?
> 

Maybe they want people to re-use old computers ? 
Maybe that highlights the difference between symmetric 
and public-private key security  ; 
people who use private key security have to make sure
they don't lose their key file, and each person would be
a bit protected by password encryption of their private key
files, 
but those using something like kerberos, might be 
vulnerable if their single kdc server files got stolen, and
the key stash file, the principals file, and the
kadm5 table file were available to a unintended root user.
 

> Limit Access to the KDCs
To limit the possibility that your Kerberos database could be
compromised, MIT recommends that each KDC be a dedicated host, with
limited access. If your KDC is also a file server, FTP server, Web
server, or even just a client machine, someone who obtained root access
through a security hole in any of those areas could gain access to the
Kerberos database. MIT recommends that your KDCs use the
following /etc/inetd.conf file. (Note: each line beginning with => is a
continuation of the previous line.):

     #
     # Configuration file for inetd(1M).  See inetd.conf(4).
     #
     # To re-configure the running inetd process, edit this file, then
     # send the inetd process a SIGHUP.
     #
     # Syntax for socket-based Internet services:
     #  <service_name> <socket_type> <proto> <flags> <user>
     => <server_pathname> <args>
     #
     # Syntax for TLI-based Internet services:
     #
     #  <service_name> tli <proto> <flags> <user> <server_pathname> <args>
     #
     # Ftp and telnet are standard Internet services.
     #
     # This machine is a secure Kerberos Key Distribution Center (KDC).
     # Services are limited.
     #
     #
     # Time service is used for clock synchronization.
     #
     time    stream  tcp     nowait  root    internal
     time    dgram   udp     wait    root    internal
     #
     # Limited Kerberos services
     #
     krb5_prop stream tcp nowait root /usr/local/sbin/kpropd  kpropd
     eklogin   stream tcp nowait root /usr/local/sbin/klogind
     => klogind -5 -c -e
     
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel
>