Default user decisions
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:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
Reply to: