On Fri, May 02, 2008 at 10:19:11AM +1000, Trent W. Buck wrote: > On Thu, May 01, 2008 at 05:39:07PM +0300, Tzafrir Cohen wrote: > > On Thu, May 01, 2008 at 09:48:45AM -0400, John Reese wrote: > >> Marco Amadori wrote: > >>> ssh wise, Ubuntu's choice is more secure, because it disallows ssh > >>> logins if the local console user did not provide a new password. > >>> > >>> I think that using a NULL password like ubuntu do and providing > >>> both an interactive way to change it and a boot parameter could > >>> be the way I would like to have the user password managed. > >>> > >>> That way we could have a more secure default image approach, a > >>> secure personal use approach and the ability to set a password > >>> easely at build time. > >> > >> I have to agree with this. I really like the Ubuntu approach to > >> securing the root/default users, and I'd like to put my support > >> behind making this behavior the preferred method. > > > > A user has to install ssh explicitly, anyway. But what happens when > > that "secure" user installs a service that doesn't care about empty > > passwords? > > What kind of user? > > - An end user running the default Debian Live system; changing the > /cow which will be lost on boot. > > - A similar end user running a customized Live system created by an > (intermediary) lh user; or > > - An (intermediary) lh user, creating a Live system with on-by-default > attackable services like ssh and httpd?
That user has installed them and should know how to secure them. Almost all httpd provide only read-only information by default. > > It seems to me that these cases are fundamentally different, and > should be considered separately. Fine. And just to remind you that openssh-server is not installed by default. Now that we mentioned httpd: here are some useful bits from my configuration: My apache hook: Usually I have a separate hook for each task. But this one gre a bit larger than usual: ################################ Begin config/chroot_local-hooks/apache #!/bin/sh # generate a certificate for apache. # FIXME: This one should really be done at runtime. Anyone can know the # "secret" key of this server. And I have no hope of using the real host # name before boot. # # But until I figure how to run things on runtime, let's generate a # "static" certificate: #export RANDFILE=/dev/random; #mkdir /etc/apache2/ssl # #openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem \ # -keyout /etc/apache2/ssl/apache.pem # [The snippet above has been replaced by a single certificate I have # generated once. Needless to say you should not consider this secure. # Thus you cannot really protect from a man-in-the-middle attack. But # what would you expect from a live CD? :-) ] # the default apache site has a NameVirtualHost for all ports. # I want to add a different one for port 443. And I don't need it # anyway: a2dissite default a2ensite default80 # Enable ssl: a2enmod ssl # Enable mod_proxy for ajaxterm: a2enmod proxy_http # Make sure apache is started by default: sed -i 's/^NO_START=.*/NO_START=0/' /etc/default/apache2 ################################ End config/chroot_local-hooks/apache As you can see, apache does not run by default. Apache is also takes some effort to create an SSL site. Here is something the reduces security a bit as it allows remote users to get an information about installed software), but then again, what do I have to hide? ;-) On the other hand it exposes all the great documentation (and has encourged me to contribute more documentation and make it available through debian-doc). ################################ Begin config/chroot_local-hooks/dwww_permit #!/bin/sh # allow anyone to browse the documentation on the CD: sed -i '/allow/s/from .*/from all/' /etc/apache2/conf.d/dpkg-www ################################ End config/chroot_local-hooks/dwww_permit I also have some useful documentation on the CD. Thus I want to expose it as well: ######### Begin config/chroot_local-includes/etc/apache2/conf.d/live_media.conf # Make the content of the CD available for apache under # http://server/media Alias /media /live_media <Directory /live_media> Options Indexes MultiViews </Directory> ######### End config/chroot_local-includes/etc/apache2/conf.d/live_media.conf I also permit access through ajaxterm. This is why I had to enable SSL. Though ajaxterm seems to be quite dead and maybe it is time to package anyterm. The configuration I use is basically the one included in the current package in Lenny. Allow web-based access to the IRC support channel. Sadly nobody really uses this. Uses the package cgiirc: ################## Begin config/chroot_local-includes/etc/cgiirc/cgiirc.config # CGI:IRC configuration file. # # Check /usr/share/doc/cgiirc/examples/cgiirc.config.full.gz # for more details. # Take care about applying debian-specific settings like # `image_path' if you intend to just copy it! default_server = irc.freenode.net default_port = 6667 default_channel = #my-channel default_name = CGI:IRC User default_nick=CGI??? # Don't change these, they're specific to Debian: image_path = /images/cgiirc # ----------------------------------------------- script_nph = nph-irc.cgi script_form = client-perl.cgi script_login = irc.cgi ip_access_file = ipaccess ################## End config/chroot_local-includes/etc/cgiirc/cgiirc.config This should not make the CD an open IRC proxy, as I limit it to one specific channel (by default). -- Tzafrir Cohen icq#16849755 jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir _______________________________________________ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
