Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 I've rewritten that in the CVS version, should be available in the website soon. Please review it in a few days. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 I've rewritten that in the CVS version, should be available in the website soon. Please review it in a few days. Regards Javier
Re: Some clarifications about the Debian-security-HOWTO
On Saturday 21 February 2004 01.14, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. The only sensible way to handle this is the current way: stating 'testing has now security support'. urgency='high' or not. I run a stable/testing/unstable mix on my computers, and when a DSA is out I take a quick look and check which versions of the package I use. Downgrading a package from a testing version to a stable version is sometimes an option, for example. cheers -- vbi -- Entre hermanos, dos testigos y un notario. pgp0.pgp Description: signature
Re: Some clarifications about the Debian-security-HOWTO
On Sat, Feb 21, 2004 at 09:09:24AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. Doesn't make a difference. The testing scripts take into account the maximum urgency between the version in testing and the version in unstable. Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Saturday 21 February 2004 01.14, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. The only sensible way to handle this is the current way: stating 'testing has now security support'. urgency='high' or not. I run a stable/testing/unstable mix on my computers, and when a DSA is out I take a quick look and check which versions of the package I use. Downgrading a package from a testing version to a stable version is sometimes an option, for example. cheers -- vbi -- Entre hermanos, dos testigos y un notario. pgpjQFE2idzaE.pgp Description: signature
Re: Some clarifications about the Debian-security-HOWTO
On Sat, Feb 21, 2004 at 09:09:24AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. Doesn't make a difference. The testing scripts take into account the maximum urgency between the version in testing and the version in unstable. Daniel.
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? The security team has nothing to do with sid packages. If a fix is ready when the advisory goes out the security team may add the sid information as a curtesy, but the lack of a sid package will in no way delay the advisory. Are the fixes *always* be applied to sid packages and then backported ? That never happens, the security HOWTO should rephrase that. I imagine that the intent is to say that sid may have a new version installed to fix a problem, but stable will get a backported patch. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. This is misleading. Security fixes for stable are prepared by the security team, while security fixes for unstable are usually prepared by the package maintainer (often by incorporating a new upstream release). Sometimes they happen at nearly the same time, and sometimes they do not. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise.
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? The security team has nothing to do with sid packages. If a fix is ready when the advisory goes out the security team may add the sid information as a curtesy, but the lack of a sid package will in no way delay the advisory. Are the fixes *always* be applied to sid packages and then backported ? That never happens, the security HOWTO should rephrase that. I imagine that the intent is to say that sid may have a new version installed to fix a problem, but stable will get a backported patch. Mike Stone
Re: Some clarifications about the Debian-security-HOWTO
On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. This is misleading. Security fixes for stable are prepared by the security team, while security fixes for unstable are usually prepared by the package maintainer (often by incorporating a new upstream release). Sometimes they happen at nearly the same time, and sometimes they do not. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. -- - mdz
Re: Debian Security-HOWTO
Christian Kurz escribió: [Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] Ok. On 00-12-04 Javier Fernandez-Sanguino Peña wrote: Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. As a matter of fact, all documents in the DDP are made as separate packages, doc-debian, for example, includes only the FAQ, the package-maintainer the document of the same name, maint-guide the New Maintainer Guide, java-common the Debian JAVA FAQ. So I would say that the standard procedure is to have this documents in different packages.. well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. Umm.. I have looked in the archive and I have only seen references to a meta-package to do automatica updates from the security.debian.org site. Did you talk on documentation and dependancies too? ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. Because the discussion in debian-devel (which I missed but I have read a resumed text on debian-planet) was centered on other issues. Was the chroot case pushed into the discussion there. I am sorry, I do *not* read debian-devel, I barely have time to keep up with the weekly news and debian planet summaries. (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. I do know that it will not work since it is not implemented in dpkg. The main issue here is: Is it useful? (security-wise) Did it make any sense? Some and please turn that v-card of. Sorry If I do, I sometimes forget to remove it when I send mails... will have to look on how to do it on a per-address basis. Javi
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian Security-HOWTO
Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... improving it. One thing I would like to have nicely documented is to make chroot jails. But not Linux-wide but Debian-specific, that is: What should be documented? Mostly you need to have all config files, libaries and binaries in the same structure as under / in a seperate dir, where you chroot to. See below. is there a way to build packages available in Debian in order to easily install them chrooted? My first thought is that only if the You don't need to statically link packages to chroot them. You can also chroot them, if they use dynamic linking, but then you need to copy these libs also into the chroot-dir. I do know. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Did it make any sense? Regards Javibegin:vcard n:Fernández-Sanguino Peña;Javier tel;fax:+34-91 806 46 41 tel;work:+34-91 806 46 40 x-mozilla-html:FALSE org:SGI-GMV sistemas;Seguridad Lógica adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;28448 fn:Javier Fernández-Sanguino Peña end:vcard
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpCR0X9pcyRf.pgp Description: PGP signature
Re: Debian Security-HOWTO
On 00-12-02 Wichert Akkerman wrote: Previously Christian Kurz wrote: How long is dpkg-statoverries available for debian? Couple of weeks. There is also the slight fact that the currently shipped version is subtly broken :(. It's still cool though! Well, from reading the changelog it's about 1 month ago and wasn't announced in a big form, so even I had no idea, that this tool exists until the discussion about it was started on -devel. I think the same applies to Alexander. But I think we will soon have some paragraph about dpkg-statoverride in it. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpalcF22sSxx.pgp Description: PGP signature
Re: Debian Security-HOWTO
On 00-12-01 Wichert Akkerman wrote: Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. How long is dpkg-statoverries available for debian? I think it was introduced only a very short time ago. So the author Alexander, had no time to really play with this tool and write a paragraph about it. (That's what I assume and may not be the reality, but I think I'm close to it :). Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian Security-HOWTO
Previously Christian Kurz wrote: How long is dpkg-statoverries available for debian? Couple of weeks. There is also the slight fact that the currently shipped version is subtly broken :(. It's still cool though! Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security-HOWTO
On 00-12-01 Wichert Akkerman wrote: Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. How long is dpkg-statoverries available for debian? I think it was introduced only a very short time ago. So the author Alexander, had no time to really play with this tool and write a paragraph about it. (That's what I assume and may not be the reality, but I think I'm close to it :). Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpJwBu2ln4XV.pgp Description: PGP signature
Re: Debian Security-HOWTO
Previously Christian Kurz wrote: How long is dpkg-statoverries available for debian? Couple of weeks. There is also the slight fact that the currently shipped version is subtly broken :(. It's still cool though! Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Debian Security-HOWTO
from the secret journal of Javier Fernandez-Sanguino Pe?a ([EMAIL PROTECTED]): I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). does the docbook source to this exist somewhere? i'd rather read this as html. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security-HOWTO
Hi On Thu, Nov 30, 2000 at 01:55:33PM -0500, Jacob Kuntz wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). does the docbook source to this exist somewhere? i'd rather read this as html. No. It's plain text only, as I do not have enough free time at the moment to take a closer look a docbook. MfG/Regards, Alexander -- Alexander Reelsen http://joker.rhwd.de [EMAIL PROTECTED] GnuPG: pub 1024D/F0D7313C sub 2048g/6AA2EDDB [EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E 7C88 EE9C CBD1 F0D7 313C Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security-HOWTO
On 00-11-30 Javier Fernandez-Sanguino Peña wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). I think he's reading this list as he's very security interested. I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? improving it. One thing I would like to have nicely documented is to make chroot jails. But not Linux-wide but Debian-specific, that is: What should be documented? Mostly you need to have all config files, libaries and binaries in the same structure as under / in a seperate dir, where you chroot to. is there a way to build packages available in Debian in order to easily install them chrooted? My first thought is that only if the You don't need to statically link packages to chroot them. You can also chroot them, if they use dynamic linking, but then you need to copy these libs also into the chroot-dir. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian Security-HOWTO
Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Security-HOWTO
I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in improving it. One thing I would like to have nicely documented is to make chroot jails. But not Linux-wide but Debian-specific, that is: is there a way to build packages available in Debian in order to easily install them chrooted? My first thought is that only if the original source uses autoconf (which would allow setting the $prefix/$exec_prefix, etc.. in order to install it correctly). Any ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) Best regards Javi
Re: Debian Security-HOWTO
from the secret journal of Javier Fernandez-Sanguino Pe?a ([EMAIL PROTECTED]): I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). does the docbook source to this exist somewhere? i'd rather read this as html. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED]
Re: Debian Security-HOWTO
Hi On Thu, Nov 30, 2000 at 01:55:33PM -0500, Jacob Kuntz wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). does the docbook source to this exist somewhere? i'd rather read this as html. No. It's plain text only, as I do not have enough free time at the moment to take a closer look a docbook. MfG/Regards, Alexander -- Alexander Reelsen http://joker.rhwd.de [EMAIL PROTECTED] GnuPG: pub 1024D/F0D7313C sub 2048g/6AA2EDDB [EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E 7C88 EE9C CBD1 F0D7 313C Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO
Re: Debian Security-HOWTO
Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
