Re: default security

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2002.03.07.1054 
+0100]:
> > >   Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> > 
> > how would it break policy?
> 
> (sorry, catching up with posts)

me too...

>   Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location 
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.

not necessarily. depends on how the daemon is written. for instance,
my bind9 chroot has absolutely zero anything in violation with the
FHS!

but i see your point. it's a flaw in the policy/FHS though, i think.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
you work very hard. don't try to think as well.


pgpZGNwJx8Y0H.pgp
Description: PGP signature

Re: default security

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2002.03.07.1054 +0100]:
> > >   Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> > 
> > how would it break policy?
> 
> (sorry, catching up with posts)

me too...

>   Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location 
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.

not necessarily. depends on how the daemon is written. for instance,
my bind9 chroot has absolutely zero anything in violation with the
FHS!

but i see your point. it's a flaw in the policy/FHS though, i think.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
  
you work very hard. don't try to think as well.



msg05981/pgp0.pgp
Description: PGP signature

Re: default security

[Xeno Campanoli]

Javier Fernández-Sanguino Peña wrote:
> 
> On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> >
> > > Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> >
> > how would it break policy?
> 
> (sorry, catching up with posts)
> 
> Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS

He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:

http://www.pathname.com/fhs/

> and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.
> This also makes it more difficult for package maintainance,
> how do I propagate changes from dynamic libraries to chrooted services?
> Of course, if the service is able to chroot itself (example is bind's
> -t flag or proftp's anonymous chrooted environment) this is less of an
> issue since you can run it properly and
> just need config, log, data and pid files in the chrooted environment.
> 
> Regards
> 
> Javi
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.

Re: default security

[Xeno Campanoli]

Javier Fernández-Sanguino Peña wrote:
> 
> On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> >
> > > Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> >
> > how would it break policy?
> 
> (sorry, catching up with posts)
> 
> Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS

He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:

http://www.pathname.com/fhs/

> and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.
> This also makes it more difficult for package maintainance,
> how do I propagate changes from dynamic libraries to chrooted services?
> Of course, if the service is able to chroot itself (example is bind's
> -t flag or proftp's anonymous chrooted environment) this is less of an
> issue since you can run it properly and
> just need config, log, data and pid files in the chrooted environment.
> 
> Regards
> 
> Javi
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Javier Fernández-Sanguino Peña]

On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> 
> > Debian could provide, with only some effort from package
> > maintainers versions of daemons chrooted to given environments. This
> > however, might break Policy (IMHO).
> 
> how would it break policy?

(sorry, catching up with posts)

Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location 
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.

Regards



Javi

Re: default security

[Javier Fernández-Sanguino Peña]

On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> 
> > Debian could provide, with only some effort from package
> > maintainers versions of daemons chrooted to given environments. This
> > however, might break Policy (IMHO).
> 
> how would it break policy?

(sorry, catching up with posts)

Policy would be broken because a chroot installation would need
all the libraries, configuration files, etc... that the service needed
to be placed in a given fixed location 
(for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
This defeats the FHS and also one of Debian's primary assumptions
(all configuration files in /etc for example) on which the policy is
based.
This also makes it more difficult for package maintainance,
how do I propagate changes from dynamic libraries to chrooted services?
Of course, if the service is able to chroot itself (example is bind's
-t flag or proftp's anonymous chrooted environment) this is less of an
issue since you can run it properly and
just need config, log, data and pid files in the chrooted environment.

Regards



Javi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Michael Wood]

On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
[snip]
> > Debian being what it is, are there any reasons why the
> > debian bind package should not be chroot as the default
> > instalation?
> 
>   RTFM. That is:
> http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
> 
>   :) 
[snip]

The above link contains the following:

FIXME (jfs): I'm not sure about this, shouldn't bind
files be chown'ed to the groups created? Some files
might need rw permissions in order for bind to work
correctly; for example: if the name server is being used
as a cache the cache files need to be written on hard
disk. Also, if the DNS server is secondary, it might
need to transfer zones from the primary and write them
on hard disk too. This should be clarified.

My opinion is that things that need to be writable should be
owned by the user that runs named, but everything else should be
owned by root.

i.e. secondary zones etc., should be owned by the user that runs
named.  If you're doing dynamic DNS, the primary zones will also
need to be writable.  named.conf (and primary zones if you're
not doing dynamic DNS) should be owned by root and not writable
by named.

This way, if there's a bind exploit, an attacker can't corrupt
your zone files or config file (except for the secondary zones.)

Of course, they may still be able to make the DNS server serve
incorrect information, but at least it's another hurdle for them
to jump over.

-- 
Michael Wood <[EMAIL PROTECTED]>

Re: default security

[Michael Wood]

On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
[snip]
> > Debian being what it is, are there any reasons why the
> > debian bind package should not be chroot as the default
> > instalation?
> 
>   RTFM. That is:
> 
>http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
> 
>   :) 
[snip]

The above link contains the following:

FIXME (jfs): I'm not sure about this, shouldn't bind
files be chown'ed to the groups created? Some files
might need rw permissions in order for bind to work
correctly; for example: if the name server is being used
as a cache the cache files need to be written on hard
disk. Also, if the DNS server is secondary, it might
need to transfer zones from the primary and write them
on hard disk too. This should be clarified.

My opinion is that things that need to be writable should be
owned by the user that runs named, but everything else should be
owned by root.

i.e. secondary zones etc., should be owned by the user that runs
named.  If you're doing dynamic DNS, the primary zones will also
need to be writable.  named.conf (and primary zones if you're
not doing dynamic DNS) should be owned by root and not writable
by named.

This way, if there's a bind exploit, an attacker can't corrupt
your zone files or config file (except for the secondary zones.)

Of course, they may still be able to make the DNS server serve
incorrect information, but at least it's another hurdle for them
to jump over.

-- 
Michael Wood <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Tim Haynes]

Tarjei <[EMAIL PROTECTED]> writes:

> Hmm. Here's a suggestion.
>
> - This idea is based on the asumtion that espesially serversystems need
> good security.

*All* installed boxes need adequate securing. Linux worms would not
propagate if it weren't for a critical mass of idiots running unpatched
daemons & packages; scanning by IP# is no respector of `this is a server'
or `this is a workstation'; it just happens that servers *have* to be
"secure" while workstations tend not to be.

> 1. Make a votingpage and anounce it on debian-users asking what are the
> main servers people are running on their debian systems.

You'd want a control poll e.g. on slashdot or somewhere as well because the
Internet as a whole will run different servers in different amounts - more
web servers than DNS than email? Or similar numbers of each?

> 2. Go through the 10 highest and make sure they follow secure practies
> like libsafe.

Personally I think a BIG disclaimer in the installer, `look, if you will
run these things, on your head be it' for every daemon that gets installed
would be in order.

[snip]
> I apoligize to all the people reading this list for filling it with rants.
> Will stop now.

~Tim
-- 

Re: default security

[Tarjei]

Hmm. Here's a suggestion.

- This idea is based on the asumtion that espesially serversystems need 
good security.


1. Make a votingpage and anounce it on debian-users asking what are the 
main servers people are running on their debian systems.


2. Go through the 10 highest and make sure they follow secure practies 
like libsafe.


3. Support security in these servers also for testing and unstable.


I think it would be worthwhile to rethink the philosophy of 
debian-stable. Instead of saying the next version of debian is stable 
when all it's packages are stable, how about defining a stable version 
of each package, and saying that stable is a dynamic target. In the age 
of highspeed conections, most most people could then install debian over 
the 'net instead of the install cd's.



I apoligize to all the people reading this list for filling it with 
rants. Will stop now.


Tarjei

Re: default security

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2002.01.15.1316 
+0100]:
> > Debian being what it is, are there any reasons why the debian bind 
> > package should not be chroot as the default instalation?
> 
>   RTFM. That is:
> http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
> 
>   :) 

well, first of all, this document refers to a bug, #50013 (to which this
is CCd). in the bug, the argument comes up that "opinions differ from
running bind non-root". but a chroot jail is advised.

i'd love to know just why you'd ever run bind as root, even in a jail.
if i have root rights in a jail, i'll break out of the jail within
minutes (e.g. [1]).

second, why would you *need* bind running as root?

and thirdly, please check the threads at [2] and [3] if you are
interested in a discussion on bind9 and chroot.

> > One thing that might be a good idea, would be a security review of the 
> > main debian packages. It's probably beeing done for some already, but I 
> > would guess a lot of debian packages could benefit from even stricter 
> > default setups. For example, maybe libsafe should be default inn all 
> > installs.
> 
>   Agreed. Feel free to point to better security measures in the
> Default installation and document them, once done it is a major point of
> pressure to change Debian policy.

running non-root *and* chrooting.

>   Debian could provide, with only some effort from package
> maintainers versions of daemons chrooted to given environments. This
> however, might break Policy (IMHO).

how would it break policy?

  1. http://www.bpfh.net/simes/computing/chroot-break.html
  2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html
  3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
above all, we should not wish to divest
our existence of its rich ambiguity.
  -- nietzsche


pgpPhGfngiiHZ.pgp
Description: PGP signature

Re: default security

[Tim Haynes]

Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:

> On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
> > >
>> >
>> >I recall there being discussion a while back about packaging chroot
>> >bind.  I don't know whether or not anything came of it at all.  There is
>> >
>> Debian being what it is, are there any reasons why the debian bind
>> package should not be chroot as the default instalation?
>
>   RTFM. That is:
> http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
>
>   :) 

 | Regarding limiting BIND's privileges you must be aware that if a
 | non-root user runs BIND, then BIND cannot detect new interfaces
 | automatically. For example, if you stick a PCMCIA card into your laptop.

Like anyone would really want to run bind automatically on all transient
interfaces... It's a *service*, to be run on *serv-ers*!
If you want a named listening on such an interface, the due pain is
deserved, IMHO.

(I've been meaning to get that off my chest for a few months :8)

The above URL links to a bug,
, which
seems to imply that chroot()ed behaviour will be expected ere long. Have I
missed it, or shall I carry on hoping? :)
 
[snip]

~Tim
-- 

Re: default security

[Javier Fernández-Sanguino Peña]

On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
> >
> >
> >I recall there being discussion a while back about packaging chroot
> >bind.  I don't know whether or not anything came of it at all.  There is
> >
> Debian being what it is, are there any reasons why the debian bind 
> package should not be chroot as the default instalation?

RTFM. That is:
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind

:) 
> 
> One thing that might be a good idea, would be a security review of the 
> main debian packages. It's probably beeing done for some already, but I 
> would guess a lot of debian packages could benefit from even stricter 
> default setups. For example, maybe libsafe should be default inn all 
> installs.

Agreed. Feel free to point to better security measures in the
Default installation and document them, once done it is a major point of
pressure to change Debian policy.

 > 
> I know this would take some time to implement, but I think it would help 
> the image of debian and linux over time. I'm often frustrated that the 
> big distros (rh, mandrake) doesn't do more to harden their distros. For 
> example the default install of ssh in RH still provides both ssh1 and 
> ssh2 & root login.
> 
Debian, unlike RedHat or Mandrake provides and gives support for
Bastille Linux. Even if the default setup is quite good (security-wise) it
can easily be made even better.

> I know this is a rant, but maybe it would be wise to think of a way to 
> implement this. At least, put more deamons in chroot jails and get 
> libsafe compiled into every package.

Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
BTW, Bastille does have modules for chrooting services (it has one
for Bind) that can be selected when hardening the system. You could also
help having Bastille's module (for Bind) adapted to Debian (I have not had
time to do so myself)

Regards

Javi

Re: default security

[Tim Haynes]

Tarjei <[EMAIL PROTECTED]> writes:

> Hmm. Here's a suggestion.
>
> - This idea is based on the asumtion that espesially serversystems need
> good security.

*All* installed boxes need adequate securing. Linux worms would not
propagate if it weren't for a critical mass of idiots running unpatched
daemons & packages; scanning by IP# is no respector of `this is a server'
or `this is a workstation'; it just happens that servers *have* to be
"secure" while workstations tend not to be.

> 1. Make a votingpage and anounce it on debian-users asking what are the
> main servers people are running on their debian systems.

You'd want a control poll e.g. on slashdot or somewhere as well because the
Internet as a whole will run different servers in different amounts - more
web servers than DNS than email? Or similar numbers of each?

> 2. Go through the 10 highest and make sure they follow secure practies
> like libsafe.

Personally I think a BIG disclaimer in the installer, `look, if you will
run these things, on your head be it' for every daemon that gets installed
would be in order.

[snip]
> I apoligize to all the people reading this list for filling it with rants.
> Will stop now.

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Tarjei]

Hmm. Here's a suggestion.

- This idea is based on the asumtion that espesially serversystems need 
good security.

1. Make a votingpage and anounce it on debian-users asking what are the 
main servers people are running on their debian systems.

2. Go through the 10 highest and make sure they follow secure practies 
like libsafe.

3. Support security in these servers also for testing and unstable.


I think it would be worthwhile to rethink the philosophy of 
debian-stable. Instead of saying the next version of debian is stable 
when all it's packages are stable, how about defining a stable version 
of each package, and saying that stable is a dynamic target. In the age 
of highspeed conections, most most people could then install debian over 
the 'net instead of the install cd's.


I apoligize to all the people reading this list for filling it with 
rants. Will stop now.

Tarjei


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2002.01.15.1316 +0100]:
> > Debian being what it is, are there any reasons why the debian bind 
> > package should not be chroot as the default instalation?
> 
>   RTFM. That is:
> 
>http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
> 
>   :) 

well, first of all, this document refers to a bug, #50013 (to which this
is CCd). in the bug, the argument comes up that "opinions differ from
running bind non-root". but a chroot jail is advised.

i'd love to know just why you'd ever run bind as root, even in a jail.
if i have root rights in a jail, i'll break out of the jail within
minutes (e.g. [1]).

second, why would you *need* bind running as root?

and thirdly, please check the threads at [2] and [3] if you are
interested in a discussion on bind9 and chroot.

> > One thing that might be a good idea, would be a security review of the 
> > main debian packages. It's probably beeing done for some already, but I 
> > would guess a lot of debian packages could benefit from even stricter 
> > default setups. For example, maybe libsafe should be default inn all 
> > installs.
> 
>   Agreed. Feel free to point to better security measures in the
> Default installation and document them, once done it is a major point of
> pressure to change Debian policy.

running non-root *and* chrooting.

>   Debian could provide, with only some effort from package
> maintainers versions of daemons chrooted to given environments. This
> however, might break Policy (IMHO).

how would it break policy?

  1. http://www.bpfh.net/simes/computing/chroot-break.html
  2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html
  3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
  
above all, we should not wish to divest
our existence of its rich ambiguity.
  -- nietzsche



msg05281/pgp0.pgp
Description: PGP signature

Re: default security

[Tim Haynes]

Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:

> On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
> > >
>> >
>> >I recall there being discussion a while back about packaging chroot
>> >bind.  I don't know whether or not anything came of it at all.  There is
>> >
>> Debian being what it is, are there any reasons why the debian bind
>> package should not be chroot as the default instalation?
>
>   RTFM. That is:
> 
>http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind
>
>   :) 

 | Regarding limiting BIND's privileges you must be aware that if a
 | non-root user runs BIND, then BIND cannot detect new interfaces
 | automatically. For example, if you stick a PCMCIA card into your laptop.

Like anyone would really want to run bind automatically on all transient
interfaces... It's a *service*, to be run on *serv-ers*!
If you want a named listening on such an interface, the due pain is
deserved, IMHO.

(I've been meaning to get that off my chest for a few months :8)

The above URL links to a bug,
, which
seems to imply that chroot()ed behaviour will be expected ere long. Have I
missed it, or shall I carry on hoping? :)
 
[snip]

~Tim
-- 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Javier Fernández-Sanguino Peña]

On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote:
> >
> >
> >I recall there being discussion a while back about packaging chroot
> >bind.  I don't know whether or not anything came of it at all.  There is
> >
> Debian being what it is, are there any reasons why the debian bind 
> package should not be chroot as the default instalation?

RTFM. That is:
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind

:) 
> 
> One thing that might be a good idea, would be a security review of the 
> main debian packages. It's probably beeing done for some already, but I 
> would guess a lot of debian packages could benefit from even stricter 
> default setups. For example, maybe libsafe should be default inn all 
> installs.

Agreed. Feel free to point to better security measures in the
Default installation and document them, once done it is a major point of
pressure to change Debian policy.

 > 
> I know this would take some time to implement, but I think it would help 
> the image of debian and linux over time. I'm often frustrated that the 
> big distros (rh, mandrake) doesn't do more to harden their distros. For 
> example the default install of ssh in RH still provides both ssh1 and 
> ssh2 & root login.
> 
Debian, unlike RedHat or Mandrake provides and gives support for
Bastille Linux. Even if the default setup is quite good (security-wise) it
can easily be made even better.

> I know this is a rant, but maybe it would be wise to think of a way to 
> implement this. At least, put more deamons in chroot jails and get 
> libsafe compiled into every package.

Debian could provide, with only some effort from package
maintainers versions of daemons chrooted to given environments. This
however, might break Policy (IMHO).
BTW, Bastille does have modules for chrooting services (it has one
for Bind) that can be selected when hardening the system. You could also
help having Bastille's module (for Bind) adapted to Debian (I have not had
time to do so myself)

Regards

Javi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: default security

[Jon Kent]

I'd agree with your comments.  I being looking at
OpenBSD (for various reasons) and the default setup is
reasonable secure (there are still some things left on
, which supprised me).  Not sure if Debian needs to go
 as far as OpenBSD but I think that it is a good
referance base

Jon
--- Tarjei <[EMAIL PROTECTED]> wrote:
> Debian being what it is, are there any reasons why
> the debian bind 
> package should not be chroot as the default
> instalation?
> 
> One thing that might be a good idea, would be a
> security review of the 
> main debian packages. It's probably beeing done for
> some already, but I 
> would guess a lot of debian packages could benefit
> from even stricter 
> default setups. For example, maybe libsafe should be
> default inn all 
> installs.
> 
> I know this would take some time to implement, but I
> think it would help 
> the image of debian and linux over time. I'm often
> frustrated that the 
> big distros (rh, mandrake) doesn't do more to harden
> their distros. For 
> example the default install of ssh in RH still
> provides both ssh1 and 
> ssh2 & root login.
>
> Tarjei
> 


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: default security

[Jon Kent]

I'd agree with your comments.  I being looking at
OpenBSD (for various reasons) and the default setup is
reasonable secure (there are still some things left on
, which supprised me).  Not sure if Debian needs to go
 as far as OpenBSD but I think that it is a good
referance base

Jon
--- Tarjei <[EMAIL PROTECTED]> wrote:
> Debian being what it is, are there any reasons why
> the debian bind 
> package should not be chroot as the default
> instalation?
> 
> One thing that might be a good idea, would be a
> security review of the 
> main debian packages. It's probably beeing done for
> some already, but I 
> would guess a lot of debian packages could benefit
> from even stricter 
> default setups. For example, maybe libsafe should be
> default inn all 
> installs.
> 
> I know this would take some time to implement, but I
> think it would help 
> the image of debian and linux over time. I'm often
> frustrated that the 
> big distros (rh, mandrake) doesn't do more to harden
> their distros. For 
> example the default install of ssh in RH still
> provides both ssh1 and 
> ssh2 & root login.
>
> Tarjei
> 


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]