Re: Root is God? (was: Mutt tmp files)
On Thu, Nov 15, 2001 at 11:46:31PM +0100, Mark Weinem wrote: On Thu, 15 Nov 2001, Craig Dickson wrote: Root is God. Anything you do on the system is potentially visible to root. What's about rsbac? Are there other strategies against root available? root usually has physical access to the hardware anyway. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04231/pgp0.pgp Description: PGP signature
Re: Root is God? (was: Mutt tmp files)
On Fri, Nov 16, 2001 at 02:36:30PM +0100, Mathias Gygax wrote: On Fre, Nov 16, 2001 at 04:13:16AM -0900, Ethan Benson wrote: Root is God. Anything you do on the system is potentially visible to root. this is, with the right patches applied, not true. What's about rsbac? Are there other strategies against root available? root usually has physical access to the hardware anyway. but root usually also does have remote access. take a look at http://www.lids.org LIDS. this is a kernel patch to seperate root from the kernel (a new level of security) by having capability and mandatory access control list support in your kernel. you can very fine tune the setup. for a real linux multi-user system, it's the perfect secruity patch. which root is free to turn off since he knows the password. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04236/pgp0.pgp Description: PGP signature
Re: Root is God? (was: Mutt tmp files)
first in this discussion root == maintianer of the box you are suggesting the maintainer of the box has no pysical access and no privileges to maintain the box. this makes no sense. On Fri, Nov 16, 2001 at 05:39:43PM +0100, Mathias Gygax wrote: i don't care. i can seal LIDS that you can only administrate your machine from the console. it doesn't work any longer over remote links. Thats like saying root doesn't have the root password. It doesn't matter, root can change the root password. this is a new way of thinking. root is there for serving purposes. with LIDS, you're sealing the kernel to not accept potentially malicious input from root. or the legit maintainer, no remote admin capabilities.. doesn't sound new sounds like NT. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04251/pgp0.pgp Description: PGP signature
Re: Root is God? (was: Mutt tmp files)
On Thu, Nov 15, 2001 at 11:46:31PM +0100, Mark Weinem wrote: On Thu, 15 Nov 2001, Craig Dickson wrote: Root is God. Anything you do on the system is potentially visible to root. What's about rsbac? Are there other strategies against root available? root usually has physical access to the hardware anyway. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpw93WLrRTEZ.pgp Description: PGP signature
Re: Root is God? (was: Mutt tmp files)
On Fri, Nov 16, 2001 at 02:36:30PM +0100, Mathias Gygax wrote: On Fre, Nov 16, 2001 at 04:13:16AM -0900, Ethan Benson wrote: Root is God. Anything you do on the system is potentially visible to root. this is, with the right patches applied, not true. What's about rsbac? Are there other strategies against root available? root usually has physical access to the hardware anyway. but root usually also does have remote access. take a look at http://www.lids.org LIDS. this is a kernel patch to seperate root from the kernel (a new level of security) by having capability and mandatory access control list support in your kernel. you can very fine tune the setup. for a real linux multi-user system, it's the perfect secruity patch. which root is free to turn off since he knows the password. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpyYBfn3IY9b.pgp Description: PGP signature
Re: Root is God? (was: Mutt tmp files)
first in this discussion root == maintianer of the box you are suggesting the maintainer of the box has no pysical access and no privileges to maintain the box. this makes no sense. On Fri, Nov 16, 2001 at 05:39:43PM +0100, Mathias Gygax wrote: i don't care. i can seal LIDS that you can only administrate your machine from the console. it doesn't work any longer over remote links. Thats like saying root doesn't have the root password. It doesn't matter, root can change the root password. this is a new way of thinking. root is there for serving purposes. with LIDS, you're sealing the kernel to not accept potentially malicious input from root. or the legit maintainer, no remote admin capabilities.. doesn't sound new sounds like NT. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp5cSV8jvJW9.pgp Description: PGP signature
Re: 2.4.x boot floppies, was: Vulnerable SSH versions
On Wed, Nov 14, 2001 at 12:42:10PM +0100, Goswin Brederlow wrote: People with such old hardware are probably better of with bo or hamm or potato. They probably need the low-mem target too. which are not (or will not in potato's case) be supported with security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04364/pgp0.pgp Description: PGP signature
Re: 2.4.x boot floppies, was: Vulnerable SSH versions
On Wed, Nov 14, 2001 at 12:42:10PM +0100, Goswin Brederlow wrote: People with such old hardware are probably better of with bo or hamm or potato. They probably need the low-mem target too. which are not (or will not in potato's case) be supported with security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpTj6ze9t1qx.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:46AM +0100, Stefan Schwandter wrote: On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. because 2.4 is not stable yet. Hmmm... I think it will take some months before woody is released. Don't you think 2.4 will have stabilized enough by that time? because then we have to break boot-floppies and start the long arduous process of stabelizing them all over again. 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. however do note that some of debian's architectures will ship with 2.4 simply because 2.2 doesn't properly support them, or 2.4 is actually more stable then 2.2 (due to the various stages porting work is/was at). for the curious here is the current rundown: ifeq $(architecture) alpha kver:= 2.2.19 endif ifeq $(architecture) arm kver:= 2.2.19 endif ifeq $(architecture) i386 kver:= 2.2.19 endif ifeq $(architecture) m68k kver:= 2.2.19 endif ifeq $(architecture) powerpc kver:= 2.2.19 pcmcia_kver := 2.2.19-pmac apuskver:= 2.2.10 endif ifeq $(architecture) sparc kver:= 2.2.19 kver_sun4u := 2.4.10 endif ifeq $(architecture) ia64 kver:= 2.4.9 endif ifeq $(architecture) hppa kver:= 2.4.9 endif ifeq $(architecture) mips kver:= 2.4.9 endif ifeq $(architecture) mipsel kver:= 2.4.9 endif ifeq $(architecture) s390 kver:= 2.4.7 endif so if you want a 2.4 kernel by default switch to one of the above 2.4 listed architectures :P otherwise just apt-get install kernel-image-2.4.YY after install. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04170/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 01:09:46PM +0100, Jørgen Hermanrud Fjeld wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 November 2001 09:52, Ethan Benson wrote: 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when compiled than the 2.2, ( I don't know though. ) quite the opposite, its much much larger. Having had the need of a 2.2.13 kernel for installing Debian on a machine with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt install lots of stuff in my kernel, it isn't overly sized. This is 'df -h' when mounting the rescue disk for 1220 floppy: /usr/src/boot-floppies/resc1200.bin 1.2M 993k 192k 84% /usr/src/boot-floppies/resc This kernel is admittedly not very versatile. I'll attach my config file as well My drivers.tgz file is quite small, but then again, I have very few modules. I assume someone have tried making 1220 floppies with 2.4.x, finding it difficult, and were not just assuming? yes, see -boot archives. And will the next generation bootstrap system make it any easier to switch? If not, what is crucial for the switch to happen? debian-installer is not anywhere near ready for prime-time and won't be used for woody, development is concentrated on boot-floppies otherwise we will never have any kind of working install system. besides the size problem the decision is not up to -boot, i386 woody will ship with 2.2.19 or 2.2.20, that is not going to change. (aph the boot-floppies maintainer has spoken on this already). -- Ethan Benson http://www.alaska.net/~erbenson/ msg04172/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:46AM +0100, Stefan Schwandter wrote: On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. because 2.4 is not stable yet. Hmmm... I think it will take some months before woody is released. Don't you think 2.4 will have stabilized enough by that time? because then we have to break boot-floppies and start the long arduous process of stabelizing them all over again. 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. however do note that some of debian's architectures will ship with 2.4 simply because 2.2 doesn't properly support them, or 2.4 is actually more stable then 2.2 (due to the various stages porting work is/was at). for the curious here is the current rundown: ifeq $(architecture) alpha kver:= 2.2.19 endif ifeq $(architecture) arm kver:= 2.2.19 endif ifeq $(architecture) i386 kver:= 2.2.19 endif ifeq $(architecture) m68k kver:= 2.2.19 endif ifeq $(architecture) powerpc kver:= 2.2.19 pcmcia_kver := 2.2.19-pmac apuskver:= 2.2.10 endif ifeq $(architecture) sparc kver:= 2.2.19 kver_sun4u := 2.4.10 endif ifeq $(architecture) ia64 kver:= 2.4.9 endif ifeq $(architecture) hppa kver:= 2.4.9 endif ifeq $(architecture) mips kver:= 2.4.9 endif ifeq $(architecture) mipsel kver:= 2.4.9 endif ifeq $(architecture) s390 kver:= 2.4.7 endif so if you want a 2.4 kernel by default switch to one of the above 2.4 listed architectures :P otherwise just apt-get install kernel-image-2.4.YY after install. -- Ethan Benson http://www.alaska.net/~erbenson/ pgptkDFeXMNI2.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 01:09:46PM +0100, Jørgen Hermanrud Fjeld wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 November 2001 09:52, Ethan Benson wrote: 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when compiled than the 2.2, ( I don't know though. ) quite the opposite, its much much larger. Having had the need of a 2.2.13 kernel for installing Debian on a machine with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt install lots of stuff in my kernel, it isn't overly sized. This is 'df -h' when mounting the rescue disk for 1220 floppy: /usr/src/boot-floppies/resc1200.bin 1.2M 993k 192k 84% /usr/src/boot-floppies/resc This kernel is admittedly not very versatile. I'll attach my config file as well My drivers.tgz file is quite small, but then again, I have very few modules. I assume someone have tried making 1220 floppies with 2.4.x, finding it difficult, and were not just assuming? yes, see -boot archives. And will the next generation bootstrap system make it any easier to switch? If not, what is crucial for the switch to happen? debian-installer is not anywhere near ready for prime-time and won't be used for woody, development is concentrated on boot-floppies otherwise we will never have any kind of working install system. besides the size problem the decision is not up to -boot, i386 woody will ship with 2.2.19 or 2.2.20, that is not going to change. (aph the boot-floppies maintainer has spoken on this already). -- Ethan Benson http://www.alaska.net/~erbenson/ pgp9UJ6NynyV6.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 11:30:49AM +0100, Michal Kara wrote: Hi there! During this weekend, there has been paper posted to bugtraq named Analysis of SSH crc32 compensation attack detector exploit. It talks about a recorded successful exploit using overflow in CRC32 compensation attack detection code, a hole, which was discovered in February this year. In the appendices, there is also program checking if you are vulnerable by checking the version string SSH daemon produces on connect. The newest Dewbian Potato version produces string SSH-1.5-OpenSSH-1.2.3 which is listed as vulnerable to this security hole. However, the Debian advisory released in February says refers to version 1.2.3 as having this fixed... So how it is? Who is wrong? debian backports security fixes to whatever version is in stable, they don't just slop new upstream versions into stable to take care of security bugs. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04143/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: I will gladly grant that the tar file may not exist for the boot floppies, and that I do not have on hand the CD to check it. It also may have been a Potato(e) phenominon, no longer in use. However, it did exist. yes releases before woody uses a base tarball. thats not done anymore, base tarballs are obsolete. Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. because 2.4 is not stable yet. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04162/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 11:30:49AM +0100, Michal Kara wrote: Hi there! During this weekend, there has been paper posted to bugtraq named Analysis of SSH crc32 compensation attack detector exploit. It talks about a recorded successful exploit using overflow in CRC32 compensation attack detection code, a hole, which was discovered in February this year. In the appendices, there is also program checking if you are vulnerable by checking the version string SSH daemon produces on connect. The newest Dewbian Potato version produces string SSH-1.5-OpenSSH-1.2.3 which is listed as vulnerable to this security hole. However, the Debian advisory released in February says refers to version 1.2.3 as having this fixed... So how it is? Who is wrong? debian backports security fixes to whatever version is in stable, they don't just slop new upstream versions into stable to take care of security bugs. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpFKqK4VNhsJ.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:56AM +0900, Howland, Curtis wrote: A quick question concerning such things... I have a remote server that I do not trust myself to upgrade from Potato(e) to Woody, and such vulnerabilities do worry me a little. Is there any general expectation that such back porting will continue once Woody is released? when potato was released security updates for slink were discontinued two monthes later. since potato is going to be even more fosselized then slink was by the time woody is released i would expect a similar timeframe (that and potato only has 6(?) architectures woody will have something like 12 or more). expect to have two months to upgrade your potato boxes before being on your own in regards to security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpbXfbo3CZy6.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:25:29AM +0900, Howland, Curtis wrote: Thanks. I've been keeping it up to date weekly or so, but just to be sure I changed the sources.list to be ... potato/... instead of ... stable/... for when stable changes. Even a blank-disk install of Woody wasn't straight forward. The kernel in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, and it's already up to 2.4.12 or .14... I wonder if the tar file has been changed to reflect the new kernel realities? what tarfile? woody will ship with 2.2.20, but it will fully support 2.4 kernels, i don't know whats so difficult about installing one. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4sMLzlcrfJ.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:41:54AM +0900, Howland, Curtis wrote: The tar file that contains the base Woody install, which is used as the jumping off point for installation. there is no such thing. The tar file has binary kernel, /boot, /proc and other directories, I'm not sure exactly what the limit to its contents is. I found this out by building a CD via the assemble the CD image from individual .deb packages procedure. there is no tarball containing any of this. boot-floppies install the kernel they were built with and then run debootstrap to install the base system from the debian archive (.debs). baseX_Y.tgz is dead and has been for a long time. As far as the change from 2.2.x to 2.4.x, if you don't think it was all that confusing then you don't use pcmcia services. The 2.2.x kernel modules are all still there, but they no longer work. That means that not only do you need to find out the new modules names, you have to ensure you don't use any of the old ones. correct i don't use pcmcia, but as i understand it pcmcia modules are obsolete in 2.4, which should save a fsckload of problems. Seriously flawed, IMNSHO, and very confusing. It also led to a version conflict with modutils, where I had to boot back into 2.2.x in order to install modutils v2.4.10. I still get error messages from modutils on both boot-up and shutdown about version conflicts and missing modules. woody will, and is of course installed with 2.4 capable modutils as for transitions of pcmcia related stuff you have to take that up with the maintainers of the relevant packages. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHSCnb7IBvH.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: I will gladly grant that the tar file may not exist for the boot floppies, and that I do not have on hand the CD to check it. It also may have been a Potato(e) phenominon, no longer in use. However, it did exist. yes releases before woody uses a base tarball. thats not done anymore, base tarballs are obsolete. Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. because 2.4 is not stable yet. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpiHMwRxTruy.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Fri, Nov 09, 2001 at 02:08:17AM +0100, Wichert Akkerman wrote: Previously Ethan Benson wrote: sorry i don't leave known security holes wide open on my boxes. only an idiot does that. If you think your box does not have currently unknown holes you are naive :) why don't you bother to read what i said. script kiddies don't exploit unknown holes as you have stated, and what i stated above is i don't leave KNOWN PATCHED holes on my boxes, those are what script kiddies attack. of course there are unknown holes, anyone exploiting those will NOT be the least bit foiled by toys like noexec /tmp. so here is the situation: i don't leave open holes that script kiddies use with thier skripts only a dumbass skript kiddie will be foiled by noexec /tmp skript kiddies will be foiled by the fact that my boxes are always up to date and patched against all known vulnerabilities. therefore noexec /tmp gives nothing but inconvenience and no added security. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04026/pgp0.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Fri, Nov 09, 2001 at 01:49:54PM +, Tim Haynes wrote: That's why, the more layers I can throw in someone's face, be it firewalling, more than just `defaults' in fstab, running libsafe, the better. sure useful things like nosuid, and nodev. noexec is worthless. as soon as everyone uses noexec all script kiddie scripts will run everything with ld to bypass it. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04115/pgp0.pgp Description: PGP signature
Re: Which ssh should I have?
On Fri, Nov 09, 2001 at 11:26:49AM +0100, Ville Uski wrote: Is there any harm from installing ssh from woody on potato? This does not apply in my case, but I'd like to know. you can't, the dependencies will drag in half of woody. you can backport the woody ssh packages to potato however. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04116/pgp0.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Fri, Nov 09, 2001 at 02:08:17AM +0100, Wichert Akkerman wrote: Previously Ethan Benson wrote: sorry i don't leave known security holes wide open on my boxes. only an idiot does that. If you think your box does not have currently unknown holes you are naive :) why don't you bother to read what i said. script kiddies don't exploit unknown holes as you have stated, and what i stated above is i don't leave KNOWN PATCHED holes on my boxes, those are what script kiddies attack. of course there are unknown holes, anyone exploiting those will NOT be the least bit foiled by toys like noexec /tmp. so here is the situation: i don't leave open holes that script kiddies use with thier skripts only a dumbass skript kiddie will be foiled by noexec /tmp skript kiddies will be foiled by the fact that my boxes are always up to date and patched against all known vulnerabilities. therefore noexec /tmp gives nothing but inconvenience and no added security. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpmSLNbzdVyo.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Fri, Nov 09, 2001 at 01:49:54PM +, Tim Haynes wrote: That's why, the more layers I can throw in someone's face, be it firewalling, more than just `defaults' in fstab, running libsafe, the better. sure useful things like nosuid, and nodev. noexec is worthless. as soon as everyone uses noexec all script kiddie scripts will run everything with ld to bypass it. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpTvwOiuvyIS.pgp Description: PGP signature
Re: Which ssh should I have?
On Fri, Nov 09, 2001 at 11:26:49AM +0100, Ville Uski wrote: Is there any harm from installing ssh from woody on potato? This does not apply in my case, but I'd like to know. you can't, the dependencies will drag in half of woody. you can backport the woody ssh packages to potato however. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp0b1P2F7F59.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Thu, Nov 08, 2001 at 03:13:05PM +0100, Emmanuel Lacour wrote: Hi, I've got an ix86 with woody installed today, made a separate partition for /tmp and mounted it noexec (I thinks it's a good Idea...). its not, it provides you NO extra security whatsoever, and will break many many things. (quite a few programs create temporary shell scripts and whatnot). try copying /bin/date to your noexec /tmp then run (varying slightly by architecture, but i386 example follows): try running /tmp/date, which fails, then run /lib/ld-linux.so.2 /tmp/date its basically the same thing as running /bin/sh /tmp/evilshellscript instead of just /tmp/evilshellscript -- Ethan Benson http://www.alaska.net/~erbenson/ msg04072/pgp0.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Thu, Nov 08, 2001 at 03:32:06PM -0800, Vineet Kumar wrote: Well, on some level, *every* system is vulnerable to scriptkiddies. The worst security flaw is admin hubris; always remember that you are not immune. sorry i don't leave known security holes wide open on my boxes. only an idiot does that. This is the whole point of a scriptkiddie; they don't know what they're dong -- they just download the sploits and run them. If they work, they work, if they don't they go on to the next machine in pac bell's DSL subnets =p if you think thats the only kind of attacker your naive. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04110/pgp0.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Thu, Nov 08, 2001 at 03:13:05PM +0100, Emmanuel Lacour wrote: Hi, I've got an ix86 with woody installed today, made a separate partition for /tmp and mounted it noexec (I thinks it's a good Idea...). its not, it provides you NO extra security whatsoever, and will break many many things. (quite a few programs create temporary shell scripts and whatnot). try copying /bin/date to your noexec /tmp then run (varying slightly by architecture, but i386 example follows): try running /tmp/date, which fails, then run /lib/ld-linux.so.2 /tmp/date its basically the same thing as running /bin/sh /tmp/evilshellscript instead of just /tmp/evilshellscript -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGI2VOLo0LA.pgp Description: PGP signature
Re: Debconf and noexec on /tmp
On Thu, Nov 08, 2001 at 03:32:06PM -0800, Vineet Kumar wrote: Well, on some level, *every* system is vulnerable to scriptkiddies. The worst security flaw is admin hubris; always remember that you are not immune. sorry i don't leave known security holes wide open on my boxes. only an idiot does that. This is the whole point of a scriptkiddie; they don't know what they're dong -- they just download the sploits and run them. If they work, they work, if they don't they go on to the next machine in pac bell's DSL subnets =p if you think thats the only kind of attacker your naive. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4uiK3NK7BA.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Sat, Oct 27, 2001 at 01:02:45AM +0200, Javier Fernández-Sanguino Peña wrote: Umm... couldn't you have a restricted environment but with commands hard-linked in it to the proper ones and restricting thoroughly the hard links? (only rX, no w bits) The problem is how to do this automatically (and not checking dynamic dependencies one by one...) not if your luser's home directories are on a different partition from / and /usr like they should be. hard links can't have different permissions from the `originals' either btw, since with hard links neither is the `real' file; they both are. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Sat, Oct 27, 2001 at 01:02:45AM +0200, Javier Fernández-Sanguino Peña wrote: Umm... couldn't you have a restricted environment but with commands hard-linked in it to the proper ones and restricting thoroughly the hard links? (only rX, no w bits) The problem is how to do this automatically (and not checking dynamic dependencies one by one...) not if your luser's home directories are on a different partition from / and /usr like they should be. hard links can't have different permissions from the `originals' either btw, since with hard links neither is the `real' file; they both are. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpCr3HQUkF0p.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote: Rishi L Khan [EMAIL PROTECTED] writes: I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. [snip] Yes. Somehow, if you're going to run something, it needs to be in the jail. Various alternatives to consider for various reasons : busybox, rbash, sash. What would be nice would be a union-mount, so you could graft a real /bin on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the same thing? mount --bind would work, but you must ask yourself why you bother with chroot if your just going to bind mount the entire filesystem into the chroot jail anyway (which is just about what you must do for things to work properly) when you bind mount /bin and /usr/bin you get all the suids in those directories in the chroot, you also need /etc for the global config files many programs use. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote: Rishi L Khan [EMAIL PROTECTED] writes: I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. [snip] Yes. Somehow, if you're going to run something, it needs to be in the jail. Various alternatives to consider for various reasons : busybox, rbash, sash. What would be nice would be a union-mount, so you could graft a real /bin on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the same thing? mount --bind would work, but you must ask yourself why you bother with chroot if your just going to bind mount the entire filesystem into the chroot jail anyway (which is just about what you must do for things to work properly) when you bind mount /bin and /usr/bin you get all the suids in those directories in the chroot, you also need /etc for the global config files many programs use. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdzIHVkJvzK.pgp Description: PGP signature
Re: Potato 2.2r3 and Kernel 2.2.19 Questions
On Wed, Oct 24, 2001 at 01:18:52AM +, Martin WHEELER wrote: On Tue, 23 Oct 2001, Ethan Benson wrote: kernels are never upgraded automatically by apt, you have to do it yourself: That's not quite true -- should you recompile your own kernel, and for whatever reason, NOT give that new kernel a debian-style name which conforms *exactly* to the debian naming conventions, you will be pestered for evermore with attempts by apt to 'upgrade' to the latest (plain vanilla) version. well yes, the reason kernel images are not automatically upgraded from r2 - r3 is because its a different package r2: kernel-image-2.2.18 Version: 2.2.18-1 r3: kernel-image-2.2.19 Version: 2.2.19-1 different package so why would apt upgrade it. (and yes i know its actually a pre-something in r2, thats beside the point). if you create your own kernel-image-2.2.19 package and your version number is not greater then the debian one then yes apt will try to upgrade it like any other package, and this in fact occurs sometimes in unstable dists since the kernel version is the same, but a few debian revisions will be done (-2 -3 -4 etc), this very rarly to never effects the stable release since by the time a new stable is released a much newer kernel is available and used. its also possible the 2.2.19 images will get a backported security patch which would cause an automatic apt upgrade for anyone with the 2.2.19 image already installed. as for your custom kernel problem the solution is trivial: make-kpkg --revision=5:2.2.19-1 or --revision=5:2.2.19-`hostname`.1 is something i use. the 5: is an epoch which will make your version number always newwer then any debian version (unless a debian kernel somehow gets an epoch larger then 5, a very unlikly scenerio). one last point, if you never actually install a kernel-image package after you install a new system from boot-floppies apt will never upgrade you kernel, since boot-floppies don't install any kernel-image they simply untar the modules into /lib/modules and cp the vmlinux files to /boot and symlink it to / dpkg never knows about it. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Potato 2.2r3 and Kernel 2.2.19 Questions
On Wed, Oct 24, 2001 at 01:18:52AM +, Martin WHEELER wrote: On Tue, 23 Oct 2001, Ethan Benson wrote: kernels are never upgraded automatically by apt, you have to do it yourself: That's not quite true -- should you recompile your own kernel, and for whatever reason, NOT give that new kernel a debian-style name which conforms *exactly* to the debian naming conventions, you will be pestered for evermore with attempts by apt to 'upgrade' to the latest (plain vanilla) version. well yes, the reason kernel images are not automatically upgraded from r2 - r3 is because its a different package r2: kernel-image-2.2.18 Version: 2.2.18-1 r3: kernel-image-2.2.19 Version: 2.2.19-1 different package so why would apt upgrade it. (and yes i know its actually a pre-something in r2, thats beside the point). if you create your own kernel-image-2.2.19 package and your version number is not greater then the debian one then yes apt will try to upgrade it like any other package, and this in fact occurs sometimes in unstable dists since the kernel version is the same, but a few debian revisions will be done (-2 -3 -4 etc), this very rarly to never effects the stable release since by the time a new stable is released a much newer kernel is available and used. its also possible the 2.2.19 images will get a backported security patch which would cause an automatic apt upgrade for anyone with the 2.2.19 image already installed. as for your custom kernel problem the solution is trivial: make-kpkg --revision=5:2.2.19-1 or --revision=5:2.2.19-`hostname`.1 is something i use. the 5: is an epoch which will make your version number always newwer then any debian version (unless a debian kernel somehow gets an epoch larger then 5, a very unlikly scenerio). one last point, if you never actually install a kernel-image package after you install a new system from boot-floppies apt will never upgrade you kernel, since boot-floppies don't install any kernel-image they simply untar the modules into /lib/modules and cp the vmlinux files to /boot and symlink it to / dpkg never knows about it. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpQxQRBWO2Ev.pgp Description: PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On Tue, Oct 23, 2001 at 01:17:14AM +0200, Javier Fernández-Sanguino Peña wrote: So, is it possible to limit those scripts or am I just thinking on trying to put a fence around the desert? (not really sure if that's the appropiate expression BTW :P even without maintainer scripts there are plenty of ways to do evil in a trojan.deb (or trojan.tgz, or trojan.rpm...) simply including an /etc/passwd with backdoor accounts comes to mind. since /etc/passwd belongs to no package dpkg won't complain. (i don't think so anyway.. i haven't tested this) of course that particular example would be noticed since the existing accounts would be gone.. but you get the idea. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On Tue, Oct 23, 2001 at 01:17:14AM +0200, Javier Fernández-Sanguino Peña wrote: So, is it possible to limit those scripts or am I just thinking on trying to put a fence around the desert? (not really sure if that's the appropiate expression BTW :P even without maintainer scripts there are plenty of ways to do evil in a trojan.deb (or trojan.tgz, or trojan.rpm...) simply including an /etc/passwd with backdoor accounts comes to mind. since /etc/passwd belongs to no package dpkg won't complain. (i don't think so anyway.. i haven't tested this) of course that particular example would be noticed since the existing accounts would be gone.. but you get the idea. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdKvhWaCgMt.pgp Description: PGP signature
Re: Potato 2.2r3 and Kernel 2.2.19 Questions
kernels are never upgraded automatically by apt, you have to do it yourself: apt-get install kernel-image-2.2.19 On Tue, Oct 23, 2001 at 07:09:43PM +0200, eim wrote: Actually I'm runnning Potato 2.2r2 on some Debian Boxes which I've upgraded to 2.2r3, the Kernel which powers the system is still 2.2.18pre21 while for the 2.2r3 Release of Potato it should be version 2.2.19 So, correct me if I'm wrong but Debian Potato 2.2r3 comes out with Kernel 2.2.19, right ? Well, if so, I want to upgrade from 2.2.18pre21 to 2.2.19, apply the new RAID Style Patch and the latest security Patch. My question is this: Debian's 2.2.19 kernel-source package is allready avaiable with the latest Kernel security patch or should I download the patch form openwall.com and apply externaly ? Thank you for suggestions, have a good work ! Ivo Marino -- Ivo Marino[EMAIL PROTECTED] UN*X Developer, running Debian GNU/Linux DALnet #flex http://eimbox.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ pgpaEw6bSymt2.pgp Description: PGP signature
Re: ssh vulernability
On Sun, Oct 21, 2001 at 04:41:17PM -0500, Mike Renfro wrote: On Fri, Oct 19, 2001 at 03:26:18PM -0800, Ethan Benson wrote: On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Has debian released a new ssh dpkg yet? no If this is about the buffer overflow exploit that's supposed to be going around now, wasn't this fixed in the following: well i assumed he was referring to the OpenSSH2 problems with authorized_keys2 among others fixed in 2.9.9p2. while this is not relevant to stable it does affect unstable users, and the sid ssh packages are still not updated to 2.9.9p2. this is not the responisibility of the security team of course. there is also the so called traffic analysis problems which stable ssh has no workarounds for. (there are patches to counteract that problem). openssh (1:1.2.3-9.2) stable; urgency=high * Non-maintainer upload by Security Team * Added backported fix for a buffer overflow (thanks to Piotr Roszatycki) * Added modified build dependencies from unstable for convenience * Added patch that fixes an rsa key exchange problem made public by CORE SDI. -- Martin Schulze [EMAIL PROTECTED] Thu, 8 Feb 2001 22:15:04 +0100 If it's a different exploit entirely, please ignore. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: ssh vulernability
On Sun, Oct 21, 2001 at 04:41:17PM -0500, Mike Renfro wrote: On Fri, Oct 19, 2001 at 03:26:18PM -0800, Ethan Benson wrote: On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Has debian released a new ssh dpkg yet? no If this is about the buffer overflow exploit that's supposed to be going around now, wasn't this fixed in the following: well i assumed he was referring to the OpenSSH2 problems with authorized_keys2 among others fixed in 2.9.9p2. while this is not relevant to stable it does affect unstable users, and the sid ssh packages are still not updated to 2.9.9p2. this is not the responisibility of the security team of course. there is also the so called traffic analysis problems which stable ssh has no workarounds for. (there are patches to counteract that problem). openssh (1:1.2.3-9.2) stable; urgency=high * Non-maintainer upload by Security Team * Added backported fix for a buffer overflow (thanks to Piotr Roszatycki) * Added modified build dependencies from unstable for convenience * Added patch that fixes an rsa key exchange problem made public by CORE SDI. -- Martin Schulze [EMAIL PROTECTED] Thu, 8 Feb 2001 22:15:04 +0100 If it's a different exploit entirely, please ignore. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ pgpoH9ybLHoUr.pgp Description: PGP signature
Re: ssh vulernability
On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: ssh vulernability
On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKxRSjHMTTx.pgp Description: PGP signature
Re: other chroot things
On Fri, Oct 05, 2001 at 02:51:46PM +, Marco Tassinari wrote: in a chroot environment with a local passwd and shadow and group files, I cannot use users. Eg, in the chrooted bash, 'ls -l' returns 0 0 for root.root files, 8.8 for mail.mail files... so my chrooted copy of sendmail freezes. It seems that the local passwd isn't there... It seems that ls doesn't use pam. (see ldd, and also experiments show this.) For me ls shows numbers, when /etc/passwd|group files are not present. Are you sure your copies are at the right place? (no symlinks of course) Mhhh... let's try: # chroot /var/users/ # ls -la /etc drwxr-xr-x3 004096 Oct 5 14:44 . drwxr-xr-x 10 004096 Oct 5 14:37 .. -rw-r--r--1 08 33 Oct 2 13:24 group drwxr-sr-x3 884096 Oct 2 13:07 mail -rw-r--r--1 08 230 Oct 3 15:52 passwd -rw-r-1 00 207 Oct 5 14:29 shadow # cat /etc/passwd root::0:0:root:/root:/bin/bash mail::8:8:mail:/var/spool/mail:/bin/bash pippo::100:100::/home/pippo:/bin/bash ls requires /lib/libnss_files.so.2 in order to map uid/gids to symbolic names. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: /dev/log
On Fri, Oct 05, 2001 at 07:41:48PM +0200, Samu wrote: hi, in these days there was a interesting thread about /dev/log that has 666 mode and some possible DOS that can be made by any user by just printing random thrash with syslog(3) and fill up the /var/log without being traced . one possible solution to that was to put /dev/log and to uid,gid syslog.syslog and then add every daemon which wants to write on log on gid syslog too. it would be a huge effort to trace down every daemon/userland utility that needs to do logging, and by the time you run them all with gid=syslog privleges along with making many things setgid syslog users won't have much trouble getting gid=syslog anyway. this is only a local user problem, anyone breaking in over the network to any deamon will end up with gid=syslog (or else the daemon won't ever log anything which is worse). the syslog man page describes how to deal with lusers behaving in this manner, it involves sucker rod. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: other chroot things
On Fri, Oct 05, 2001 at 02:51:46PM +, Marco Tassinari wrote: in a chroot environment with a local passwd and shadow and group files, I cannot use users. Eg, in the chrooted bash, 'ls -l' returns 0 0 for root.root files, 8.8 for mail.mail files... so my chrooted copy of sendmail freezes. It seems that the local passwd isn't there... It seems that ls doesn't use pam. (see ldd, and also experiments show this.) For me ls shows numbers, when /etc/passwd|group files are not present. Are you sure your copies are at the right place? (no symlinks of course) Mhhh... let's try: # chroot /var/users/ # ls -la /etc drwxr-xr-x3 004096 Oct 5 14:44 . drwxr-xr-x 10 004096 Oct 5 14:37 .. -rw-r--r--1 08 33 Oct 2 13:24 group drwxr-sr-x3 884096 Oct 2 13:07 mail -rw-r--r--1 08 230 Oct 3 15:52 passwd -rw-r-1 00 207 Oct 5 14:29 shadow # cat /etc/passwd root::0:0:root:/root:/bin/bash mail::8:8:mail:/var/spool/mail:/bin/bash pippo::100:100::/home/pippo:/bin/bash ls requires /lib/libnss_files.so.2 in order to map uid/gids to symbolic names. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4TFHOc7HWj.pgp Description: PGP signature
Re: /dev/log
On Fri, Oct 05, 2001 at 07:41:48PM +0200, Samu wrote: hi, in these days there was a interesting thread about /dev/log that has 666 mode and some possible DOS that can be made by any user by just printing random thrash with syslog(3) and fill up the /var/log without being traced . one possible solution to that was to put /dev/log and to uid,gid syslog.syslog and then add every daemon which wants to write on log on gid syslog too. it would be a huge effort to trace down every daemon/userland utility that needs to do logging, and by the time you run them all with gid=syslog privleges along with making many things setgid syslog users won't have much trouble getting gid=syslog anyway. this is only a local user problem, anyone breaking in over the network to any deamon will end up with gid=syslog (or else the daemon won't ever log anything which is worse). the syslog man page describes how to deal with lusers behaving in this manner, it involves sucker rod. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJwFH9aYtks.pgp Description: PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sun, Sep 23, 2001 at 06:39:37PM +0300, Ilkka Tuohela wrote: Quite true. Only thing which could cause this is that there were a severe security flaw found with version of ssh for potato, for which a patch were not available and only way to fix the bug were to upgrade to the 2.9 version. This is really unprobable, anyway. nope the security team would backport the fix. the only time they don't do that is if the fix is so complicated and ingrained in the 2.x series that backporting would be more risky and problematic then a new upstream. about the only package that quailifies there is gnupg, the security team doesn't backport fixes to that package generally, but the new upstreams only fix the security holes anyway so backporting them would be roughly equivilent to new upstream minus new version number.. One thing users of these custom packages must remember is that their system now has something which is not supported: if a security flaw were found from openssh 2.9xx which doesn't exist in potato version the user must compile a new version by themselves, it's never upgraded with apt-get upgrade from official servers. indeed. you have to be cautious with how many packages you backport and start monitoring them yourselves. though keeping an eye on security problems is a good idea anyway since debian sometimes doesn't make security updates, or takes wy to long. proposed-updates has a potato libc update with only a security related change thats been there for months, also there is a procmail in proposed-updates fixing a signal vulnerability (root hole most likely since its setuid root by default), its been there for quite a while now. w3m has a hole thats only been silently fixed in i386 security.debian.org (perhaps others, powerpc has an uninstallable update). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sun, Sep 23, 2001 at 06:39:37PM +0300, Ilkka Tuohela wrote: Quite true. Only thing which could cause this is that there were a severe security flaw found with version of ssh for potato, for which a patch were not available and only way to fix the bug were to upgrade to the 2.9 version. This is really unprobable, anyway. nope the security team would backport the fix. the only time they don't do that is if the fix is so complicated and ingrained in the 2.x series that backporting would be more risky and problematic then a new upstream. about the only package that quailifies there is gnupg, the security team doesn't backport fixes to that package generally, but the new upstreams only fix the security holes anyway so backporting them would be roughly equivilent to new upstream minus new version number.. One thing users of these custom packages must remember is that their system now has something which is not supported: if a security flaw were found from openssh 2.9xx which doesn't exist in potato version the user must compile a new version by themselves, it's never upgraded with apt-get upgrade from official servers. indeed. you have to be cautious with how many packages you backport and start monitoring them yourselves. though keeping an eye on security problems is a good idea anyway since debian sometimes doesn't make security updates, or takes wy to long. proposed-updates has a potato libc update with only a security related change thats been there for months, also there is a procmail in proposed-updates fixing a signal vulnerability (root hole most likely since its setuid root by default), its been there for quite a while now. w3m has a hole thats only been silently fixed in i386 security.debian.org (perhaps others, powerpc has an uninstallable update). -- Ethan Benson http://www.alaska.net/~erbenson/ pgp8hBYfHOj1y.pgp Description: PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 10:30:53AM +0200, Luca Gibelli wrote: I created a new account for testing purposes and put the following limits on its password age: known bug in potato's ssh, password expiration simply doesn't work with it, as soon as it expires ssh denies access flat out. your only option is either upgrading to woody or backporting the woody ssh package to potato (probably not very hard at all). i recommend backporting the sid ssh packages to potato. if someone hasn't already done that... -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 03:29:47PM +0200, Oyvind A. Holm wrote: In fact I think the OpenSSH distributed with potato should be upgraded. I could not use the version shipped with potato as it did not understand protocol 2 which is a must. When trying to install OpenSSH-2.2p2 (I think) from woody, dependencies with libc6-dev and locales broke, they expect libc6 = 2.1.3-18, but OpenSSH needs libc6-2.2.4-1. Quite weird it needs just that specific version - should not the newer versions also work? Well, it messed up apt-get entirely, no packages linked against newwer libc won't run against older versions of libc (usually). and as a very new Debian user (less than a week) not too used to apt-get and dpkg I just reinstalled the whole thing. woody binary packages are not compatible with potato. deal with it. thats why i said *backport* the woody packages to potato, that does NOT mean `download woody packages and run dpkg -i on them' It resulted in me getting the whole OpenSSH, OpenSSL and zlib, compiling and putting it under a new directory /usr/local/noapt/ to avoid collisions with apt-get. you don't need to do that. Is there a clean way of upgrading the SSH package and avoid the conflicts? yes compile the woody source package on potato, then it will be linked against potato libc instead of woody libc. sometimes you have to do some changes to the packages debian build process since some packages use dpkg features not present in potato, or use new features in debhelper not present in potato. anyone with basic shell scripting and a bit of Makefile experience should be able to handle that with not much difficulty. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 05:55:01PM +0300, Ilkka Tuohela wrote: It resulted in me getting the whole OpenSSH, OpenSSL and zlib, compiling and putting it under a new directory /usr/local/noapt/ to avoid collisions with apt-get. Is there a clean way of upgrading the SSH package and avoid the conflicts? Add a deb-src line to /etc/apt/sources.list, pointing to unstable, something like: deb-src ftp://ftp.fti.debian.org/debian-non-US unstable non-US/main non-US/contrib non-US/non-free you don't need contrib and non-free. Then, do apt-get update apt-get -b source ssh Quite likely the build fails first if you don't have all the libraries and -dev packets the build needs. You can continue in openssh-2.9b2 directory with dpkg-buildpackage, for example. grep ^Build debian/control and install all listed build-depends packages. This leaves you with custom ssh packages: this is the only way until the new version is backported. which will never happen, except possibly by someone doing it unofficially. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 11:14:43AM -0400, Hubert Chan wrote: As root: # apt-get build-dep openssh that doesn't work on pototo's apt. you have to do it the old way: cd openssh-* grep ^Build debian/control look at list and apt-get install each package. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 10:30:53AM +0200, Luca Gibelli wrote: I created a new account for testing purposes and put the following limits on its password age: known bug in potato's ssh, password expiration simply doesn't work with it, as soon as it expires ssh denies access flat out. your only option is either upgrading to woody or backporting the woody ssh package to potato (probably not very hard at all). i recommend backporting the sid ssh packages to potato. if someone hasn't already done that... -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIZsQ3n3yPs.pgp Description: PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 03:29:47PM +0200, Oyvind A. Holm wrote: In fact I think the OpenSSH distributed with potato should be upgraded. I could not use the version shipped with potato as it did not understand protocol 2 which is a must. When trying to install OpenSSH-2.2p2 (I think) from woody, dependencies with libc6-dev and locales broke, they expect libc6 = 2.1.3-18, but OpenSSH needs libc6-2.2.4-1. Quite weird it needs just that specific version - should not the newer versions also work? Well, it messed up apt-get entirely, no packages linked against newwer libc won't run against older versions of libc (usually). and as a very new Debian user (less than a week) not too used to apt-get and dpkg I just reinstalled the whole thing. woody binary packages are not compatible with potato. deal with it. thats why i said *backport* the woody packages to potato, that does NOT mean `download woody packages and run dpkg -i on them' It resulted in me getting the whole OpenSSH, OpenSSL and zlib, compiling and putting it under a new directory /usr/local/noapt/ to avoid collisions with apt-get. you don't need to do that. Is there a clean way of upgrading the SSH package and avoid the conflicts? yes compile the woody source package on potato, then it will be linked against potato libc instead of woody libc. sometimes you have to do some changes to the packages debian build process since some packages use dpkg features not present in potato, or use new features in debhelper not present in potato. anyone with basic shell scripting and a bit of Makefile experience should be able to handle that with not much difficulty. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpFGc1mKqqWy.pgp Description: PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 05:55:01PM +0300, Ilkka Tuohela wrote: It resulted in me getting the whole OpenSSH, OpenSSL and zlib, compiling and putting it under a new directory /usr/local/noapt/ to avoid collisions with apt-get. Is there a clean way of upgrading the SSH package and avoid the conflicts? Add a deb-src line to /etc/apt/sources.list, pointing to unstable, something like: deb-src ftp://ftp.fti.debian.org/debian-non-US unstable non-US/main non-US/contrib non-US/non-free you don't need contrib and non-free. Then, do apt-get update apt-get -b source ssh Quite likely the build fails first if you don't have all the libraries and -dev packets the build needs. You can continue in openssh-2.9b2 directory with dpkg-buildpackage, for example. grep ^Build debian/control and install all listed build-depends packages. This leaves you with custom ssh packages: this is the only way until the new version is backported. which will never happen, except possibly by someone doing it unofficially. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpVkJ59j1ymC.pgp Description: PGP signature
Re: password expire and sshd doesn't allow ppl to change it
On Sat, Sep 22, 2001 at 11:14:43AM -0400, Hubert Chan wrote: As root: # apt-get build-dep openssh that doesn't work on pototo's apt. you have to do it the old way: cd openssh-* grep ^Build debian/control look at list and apt-get install each package. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpY0GD0P3QF1.pgp Description: PGP signature
Re: setuid changes
apt-get install sxid On Fri, Sep 21, 2001 at 10:22:29AM -0700, Micah Anderson wrote: I was thinking it would be nice to see what sort of new setuid programs show up on my box each day... then I noticed that these are already being logged in /var/log/setuid.today and /var/log/setuid.yesterday. What makes these? It appears they come from /etc/cron.daily/standard which runs /usr/sbin/checksecurity. But, what is the point of logging these each day into /var/log/setuid.changes if nobody sees them? Why doesn't this list get emailed to root? Am I missing something? Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: setuid changes
apt-get install sxid On Fri, Sep 21, 2001 at 10:22:29AM -0700, Micah Anderson wrote: I was thinking it would be nice to see what sort of new setuid programs show up on my box each day... then I noticed that these are already being logged in /var/log/setuid.today and /var/log/setuid.yesterday. What makes these? It appears they come from /etc/cron.daily/standard which runs /usr/sbin/checksecurity. But, what is the point of logging these each day into /var/log/setuid.changes if nobody sees them? Why doesn't this list get emailed to root? Am I missing something? Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBsIAzS6zjF.pgp Description: PGP signature
Re: Layne (was: Re: Is ident secure?)
On Sat, Sep 01, 2001 at 01:56:16PM +1000, CaT wrote: On Fri, Aug 31, 2001 at 11:52:07PM -0400, Paul Visscher wrote: Ed Street [[EMAIL PROTECTED]] said: Hello, Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... He'll probably have to confirm and not do it. indeed, but he had to confirm when he subscribed in the first place. i don't buy it for one minute that he just magically got subscribed by no effort of himself. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Is ident secure?
On Fri, Aug 31, 2001 at 08:09:23PM -0700, Scott Sawyer wrote: Hey dude, the advice was fairly clear and didn't seem to be derogatory that I read. Just remember we all started out as clueless. not THAT clueless! -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Layne (was: Re: Is ident secure?)
On Sat, Sep 01, 2001 at 01:56:16PM +1000, CaT wrote: On Fri, Aug 31, 2001 at 11:52:07PM -0400, Paul Visscher wrote: Ed Street [EMAIL PROTECTED] said: Hello, Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... He'll probably have to confirm and not do it. indeed, but he had to confirm when he subscribed in the first place. i don't buy it for one minute that he just magically got subscribed by no effort of himself. -- Ethan Benson http://www.alaska.net/~erbenson/ pgprfmtuPOVHS.pgp Description: PGP signature
Re: Is ident secure?
On Fri, Aug 31, 2001 at 08:09:23PM -0700, Scott Sawyer wrote: Hey dude, the advice was fairly clear and didn't seem to be derogatory that I read. Just remember we all started out as clueless. not THAT clueless! -- Ethan Benson http://www.alaska.net/~erbenson/ pgpqZxSBpyMWX.pgp Description: PGP signature
Re: Is ident secure?
On Fri, Aug 31, 2001 at 04:45:05AM +0200, Martin F Krafft wrote: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? honest question: whose business is the name of a user who initiated a connection??? identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and that, so install oidentd, which has a feature to return random user names, but other than that, don't worry about it. ident is a hacker's this is a severe exaggeration. most people who bitch about identd don't even understand what its for. friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. why not? in most cases they will know anyway because most services either must run as root, or not, if its a nonroot service what the actual username is really isn't useful nor important. security through obscurity is all your really gaining. i am more concerned that the services i run are properly configured and have all security updates applied then whether someone knows what userid they are running as. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Is ident secure?
On Thu, Aug 30, 2001 at 07:52:23PM -0700, Vineet Kumar wrote: You're probably seeing most of those ident requests coming from mail and irc servers your host connects to. I think best practice is to DENY (rather than DROP) incoming traffic on 113. This makes it so that auth requests are denied quickly, rather than waiting for a TCP timeout. wrong. DENY is a ipchains target which is the same as iptables DROP. both simply drop the packet on the floor with no reply whatsoever, this will cause a severe delay as the other end must wait for the connection to timeout before proceeding. in both ipchains and iptables you should use REJECT. You really shouldn't need to enable an ident server, but if you find that you do (e.g. your users insist on connecting to irc servers which require it) try nullidentd. It comes with a short rant on why ident sucks, and just returns foobar for every ident request. if your the only user on your machine then identd isn't of much use. however if you DO have users then identd can be very useful. the problem is most people don't understand what its for. identd is for the admin RUNNING the identd, not for the admin making identd requests, if one of your users is abusing someones network in some way (attempting to send spam, causing trouble on some irc network etc) the admin of the affected site will contact you (the admin of your site) and inform you of a troublesome user, he can then supply log snippets relevant to the alleged transgressions, complete with ident responses from your machines, if you configured your identd not to lie, and not to allow your users to make it lie you will most likely have an accurate pointer to the troublemaker so you can proceed to lart them. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Is ident secure?
On Fri, Aug 31, 2001 at 04:45:05AM +0200, Martin F Krafft wrote: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? honest question: whose business is the name of a user who initiated a connection??? identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and that, so install oidentd, which has a feature to return random user names, but other than that, don't worry about it. ident is a hacker's this is a severe exaggeration. most people who bitch about identd don't even understand what its for. friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. why not? in most cases they will know anyway because most services either must run as root, or not, if its a nonroot service what the actual username is really isn't useful nor important. security through obscurity is all your really gaining. i am more concerned that the services i run are properly configured and have all security updates applied then whether someone knows what userid they are running as. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp5tRNDsHbzf.pgp Description: PGP signature
Re: Is ident secure?
On Thu, Aug 30, 2001 at 07:52:23PM -0700, Vineet Kumar wrote: You're probably seeing most of those ident requests coming from mail and irc servers your host connects to. I think best practice is to DENY (rather than DROP) incoming traffic on 113. This makes it so that auth requests are denied quickly, rather than waiting for a TCP timeout. wrong. DENY is a ipchains target which is the same as iptables DROP. both simply drop the packet on the floor with no reply whatsoever, this will cause a severe delay as the other end must wait for the connection to timeout before proceeding. in both ipchains and iptables you should use REJECT. You really shouldn't need to enable an ident server, but if you find that you do (e.g. your users insist on connecting to irc servers which require it) try nullidentd. It comes with a short rant on why ident sucks, and just returns foobar for every ident request. if your the only user on your machine then identd isn't of much use. however if you DO have users then identd can be very useful. the problem is most people don't understand what its for. identd is for the admin RUNNING the identd, not for the admin making identd requests, if one of your users is abusing someones network in some way (attempting to send spam, causing trouble on some irc network etc) the admin of the affected site will contact you (the admin of your site) and inform you of a troublesome user, he can then supply log snippets relevant to the alleged transgressions, complete with ident responses from your machines, if you configured your identd not to lie, and not to allow your users to make it lie you will most likely have an accurate pointer to the troublemaker so you can proceed to lart them. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpg1WIIWAlf6.pgp Description: PGP signature
Re: Is ident secure?
On Fri, Aug 31, 2001 at 11:44:42AM +0200, Martin F Krafft wrote: okay, i give you that, but still, i have yet to encounter one sensibly good use for ident. any shots? i already posted it in another message. why not? in most cases they will know anyway because most services either must run as root, or not, if its a nonroot service what the actual username is really isn't useful nor important. well, while my named runs may run as user bind and my proftpd as user proftpd and my apache as www-data, there are *plenty* of people who run these things as root. it's nice to determine first whether named is running as root before cracking it... rubbish, if the admin is incompetent enough to be running these things as root he will have a cracked box regardless of whether identd is running or not. and all the zillions of bind exploit attempts i get, they are NEVER preceeded by ident queries. your line of reasoning here is completly flawed. that's one of the many other parts of being security-concious... there is such a thing as going overboard with irrlevant minutia. my isp recently thought it would be a good idea to make /home unreadable by all its users for `security' reasons, of course this makes everyones shell puke when it cannot properly ascertain the pwd so they seem to have changed thier minds on this. (that and cat /etc/passwd will reveal everything ls -l /home would) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpQ3jK1E0Azy.pgp Description: PGP signature
Re: Sniffing SSH and HTTPS
On Wed, Aug 29, 2001 at 01:40:20PM +0100, Eric E Moore wrote: Michael == Michael Wood [EMAIL PROTECTED] writes: Michael Ahhh, but this is quite easily guessable, since for most Michael stuff you type, the server echos it. For passwords, it Michael doesn't. i.e. just watch the SSH session, and when you see Michael packets going to the server that aren't being echoed you know Michael the person is typing a password and you can count the Michael characters. Frightening that echoing *'s for the password could actually have security *advantages*. OpenSSH 2.something (2.5.2 i think) added a mechenism where it sends random noop packets back and forth, so it becomes difficult to impossible to determine when a password is being typed, it also throws a monkey wrench in this whole `sniffing encrypted sessions' nonsense. Solar Designer's analysis talked about this iirc. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Sniffing SSH and HTTPS
On Wed, Aug 29, 2001 at 01:40:20PM +0100, Eric E Moore wrote: Michael == Michael Wood [EMAIL PROTECTED] writes: Michael Ahhh, but this is quite easily guessable, since for most Michael stuff you type, the server echos it. For passwords, it Michael doesn't. i.e. just watch the SSH session, and when you see Michael packets going to the server that aren't being echoed you know Michael the person is typing a password and you can count the Michael characters. Frightening that echoing *'s for the password could actually have security *advantages*. OpenSSH 2.something (2.5.2 i think) added a mechenism where it sends random noop packets back and forth, so it becomes difficult to impossible to determine when a password is being typed, it also throws a monkey wrench in this whole `sniffing encrypted sessions' nonsense. Solar Designer's analysis talked about this iirc. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpAlAQsZTN3c.pgp Description: PGP signature
Re: Sniffing SSH and HTTPS
On Tue, Aug 28, 2001 at 06:44:59PM +0200, Davy Gigan wrote: Jan-Hendrik Palic writes: http://ettercap.sourceforge.net/ Is it possible? Are SSH und HTTPS connections unsecure and how do we make is secure than? old ssh protocol v1.5 IS a security hole, you can snif it. I don't know any vulnerability for the last OpenSSH_2.9p2 or OpenSSH_2.5.2p2 (which is last in debian security's updates) wrong, the latest ssh in debian's security updates (thus for potato) is Version: 1:1.2.3-9.3 the latest in unstable is 2.9p2, testing (woody) has 2.5.2p2, these are unreleased versions of debian though. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvabTD2hvz8.pgp Description: PGP signature
Re: pop3
On Sun, Jul 29, 2001 at 06:14:49PM -0600, Hubert Chan wrote: PS. Please wrap your lines at 72-ish characters. Hmm. I've seen a lot of mutt users with un-wrapped lines. I would've expected that from a GUI mail reader like Mozilla, but not from a proper mailreader like mutt. Anyone know why? not configuring $EDITOR correctly. mutt doesn't have an editor, it uses vi, emacs or whatever you set $EDITOR to. for emacs add this to your ~/.emacs: (setq auto-mode-alist (cons '(/tmp/mutt* . auto-fill-mode) auto-mode-alist)) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: pop3
On Sun, Jul 29, 2001 at 06:14:49PM -0600, Hubert Chan wrote: PS. Please wrap your lines at 72-ish characters. Hmm. I've seen a lot of mutt users with un-wrapped lines. I would've expected that from a GUI mail reader like Mozilla, but not from a proper mailreader like mutt. Anyone know why? not configuring $EDITOR correctly. mutt doesn't have an editor, it uses vi, emacs or whatever you set $EDITOR to. for emacs add this to your ~/.emacs: (setq auto-mode-alist (cons '(/tmp/mutt* . auto-fill-mode) auto-mode-alist)) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJryxUPP8V8.pgp Description: PGP signature
Re: umask for init
On Tue, Jul 24, 2001 at 02:24:41AM +0200, Nick Name wrote: More seriously, a quick fix could be, if you can't switch back 2.2.19 or go forward 2.4.7, to mv /sbin/init /sbin/good_init and put in /sbin/init a script like this, everything is untested of course: #!/bin/sh umask 022 exec /sbin/init neh. messing around with what /sbin/init is nasty. better solution is adding umask 022 to /etc/init.d/rc, using /etc/initscript (im not totally sure how this works rtfm...) or patching init to call umask(022); the kernel developers seem to beleive the latter is the correct solution, i tend to agree to that, but i don't agree that the kernel should start processes with a broken umask to begin with. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: umask for init
On Tue, Jul 24, 2001 at 02:24:41AM +0200, Nick Name wrote: More seriously, a quick fix could be, if you can't switch back 2.2.19 or go forward 2.4.7, to mv /sbin/init /sbin/good_init and put in /sbin/init a script like this, everything is untested of course: #!/bin/sh umask 022 exec /sbin/init neh. messing around with what /sbin/init is nasty. better solution is adding umask 022 to /etc/init.d/rc, using /etc/initscript (im not totally sure how this works rtfm...) or patching init to call umask(022); the kernel developers seem to beleive the latter is the correct solution, i tend to agree to that, but i don't agree that the kernel should start processes with a broken umask to begin with. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGQRIPxC2av.pgp Description: PGP signature
Re: umask for init
On Mon, Jul 23, 2001 at 04:53:55PM -0400, Dan Christensen wrote: I read that certain kernel versions don't set the umask for init correctly (2.4.6 is one of them, I think). Does anyone know if a Debian system is susceptible to this problem, and if so, which files may have been created world-writable? kernels 2.4.3 - 2.4.6 set the umask to 000 so any thread/process created by the kernel, including init started with umask 000 and remained that way unless init changed it itself. debian's init does NOT change the umask, and even though there is a umask 022 in /etc/init.d/rcS that is not enough. the result is most .pid files in /var/run/* will be created world writable with 0666 permissions as well as any other file created in the boot process, including: (if it did not exist at boot time) /lib/modules/`uname -r`/modules.dep this is a gaping root hole. /etc/modules.conf (if you have alsa-* packages installed which run update-modules in the initscript). this is another gaping root hole. there are likely more, it depends on what packages you have installed with initscripts, since most of them don't alter thier umask either in the initscript or via the program itself any file created by it will be world writable, depending on what the file is it can be a severe security hole. solution: switch back to 2.2 kernels or upgrade to 2.4.7 which finally fixes this and sets the default umask back to 022. after fixing your kernel it is highly advisable to check your system for world writable files and make sure any that are found are supposed to be that way: find / -perm +0002 ! -type l ! -type c -ls the ! -type l ! -type c ignores symlinks (which are always mode 0777) and character device files (all unused ptys are supposed to be 0666 so including this in your find will clutter the output to the point of unusability) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: umask for init
On Mon, Jul 23, 2001 at 04:53:55PM -0400, Dan Christensen wrote: I read that certain kernel versions don't set the umask for init correctly (2.4.6 is one of them, I think). Does anyone know if a Debian system is susceptible to this problem, and if so, which files may have been created world-writable? kernels 2.4.3 - 2.4.6 set the umask to 000 so any thread/process created by the kernel, including init started with umask 000 and remained that way unless init changed it itself. debian's init does NOT change the umask, and even though there is a umask 022 in /etc/init.d/rcS that is not enough. the result is most .pid files in /var/run/* will be created world writable with 0666 permissions as well as any other file created in the boot process, including: (if it did not exist at boot time) /lib/modules/`uname -r`/modules.dep this is a gaping root hole. /etc/modules.conf (if you have alsa-* packages installed which run update-modules in the initscript). this is another gaping root hole. there are likely more, it depends on what packages you have installed with initscripts, since most of them don't alter thier umask either in the initscript or via the program itself any file created by it will be world writable, depending on what the file is it can be a severe security hole. solution: switch back to 2.2 kernels or upgrade to 2.4.7 which finally fixes this and sets the default umask back to 022. after fixing your kernel it is highly advisable to check your system for world writable files and make sure any that are found are supposed to be that way: find / -perm +0002 ! -type l ! -type c -ls the ! -type l ! -type c ignores symlinks (which are always mode 0777) and character device files (all unused ptys are supposed to be 0666 so including this in your find will clutter the output to the point of unusability) -- Ethan Benson http://www.alaska.net/~erbenson/ pgppiPWysg2pl.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 09:02:54PM -0700, Jacob Meuser wrote: Oh, I guess anyone can say something like Four years without a remote hole in the default install! on the internet, where anyone is free to that quote is pure marketing. they don't count the recent ftpd remote root hole in that `four years' because they stopped activitating ftpd in the default install of OpenBSD 2.7, which was released only a very short time before the hole was discovered. the kernel hole (basically the same ptrace race the linux kernel had previous to 2.2.19) was only locally exploitable so that `doesn't count' since its not remote. prove them wrong, and get away with it? Assuming it is rubbish, as you say. try reading bugtraq. If anyone who reads the posts I made looks at them with an objective outlook, they will see that my message is clearly stated. no its not you change your position every time a falicy is pointed out. Starting services by default is a bad idea. and you keep pointing at OpenBSD as an example of a distribution that doesn't start any services, if you had ever actually installed an OpenBSD box you would see that is not true. as for debian services are only started if you install them, a very logical assumption. criticising debian's choices in regards to what services are priority: standard could be a valid argument. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 07:42:28AM +0200, Martin Bieder wrote: WARNING: You have started this car! You are about to drive this car. That means, you will be moving, what means that accidents could be harmful for you. Do you really want to proceed? [Yes] [No][Abort] Do you want something like that? or: WARNING: Coffee is served HOT! [0] -- Ethan Benson http://www.alaska.net/~erbenson/ [0] for those who don't remember there was a case some years ago where a woman sued McDonalds after she spilled a cup of thier coffee in her lap and as a result was burned, her argument was that she didn't know coffee was hot. This is why to this day McDonalds' coffee cups have a warning printed all around them saying: WARNING COFFEE IS HOT!! -- at least in the lawsuit happy US. PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 11:39:36PM -0700, Jacob Meuser wrote: I think it is quite fitting. i think is a 21st century varient of Godwin's law developing. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:37:29AM -0700, Jacob Meuser wrote: For the last time: I am saying that apt-get install should not immediately start a service, and it should not install the startup links in /etc/rc?.d. I could give a rats @$$ about what is Debian's base system. Those aren't installed with apt-get install anyway. I could give two $#1+$ about whether or not an OS is secure out of the box. This is not a question about OSes, it's a question about installing packages that install services. oh so your trying to sluff your own ignorance and incompetence onto debian because you installed a zillion services and didn't know what they did thus opening lots of `security holes'. yeah whatever. what part of `don't install the service if you don't need it/don't know how to configure it' don't you understand? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 07:11:04PM +1000, CaT wrote: On Sun, Jul 22, 2001 at 02:08:36AM -0700, Jacob Meuser wrote: I mentioned that OpenBSD has a policy of not starting services by default. Ethan Benson went off on how OpenBSD is rubbish. As no i said the claim that OpenBSD starts no services was rubbish. NOT that openbsd was rubbish. an OpenBSD user, I felt I should point out that he was the one full of rubbish. I really don't care whether people think it's your the own who is full of it Jacob. If you only wanted to talk about apt-get you should've stuck to it. yup. a good idea or not. I just wish they'd discuss the issue I'm talking about. I mean really, Ethan claimed I never installed OpenBSD. How could he have ever known whether or not that is true? Someone called ME a troll!?!?!?!?! because you (Jacob) made it quite clear you don't know anything about OpenBSD by making claims about it which are not true at all. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 09:02:54PM -0700, Jacob Meuser wrote: Oh, I guess anyone can say something like Four years without a remote hole in the default install! on the internet, where anyone is free to that quote is pure marketing. they don't count the recent ftpd remote root hole in that `four years' because they stopped activitating ftpd in the default install of OpenBSD 2.7, which was released only a very short time before the hole was discovered. the kernel hole (basically the same ptrace race the linux kernel had previous to 2.2.19) was only locally exploitable so that `doesn't count' since its not remote. prove them wrong, and get away with it? Assuming it is rubbish, as you say. try reading bugtraq. If anyone who reads the posts I made looks at them with an objective outlook, they will see that my message is clearly stated. no its not you change your position every time a falicy is pointed out. Starting services by default is a bad idea. and you keep pointing at OpenBSD as an example of a distribution that doesn't start any services, if you had ever actually installed an OpenBSD box you would see that is not true. as for debian services are only started if you install them, a very logical assumption. criticising debian's choices in regards to what services are priority: standard could be a valid argument. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpcIUb0NnbrZ.pgp Description: PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 07:42:28AM +0200, Martin Bieder wrote: WARNING: You have started this car! You are about to drive this car. That means, you will be moving, what means that accidents could be harmful for you. Do you really want to proceed? [Yes] [No][Abort] Do you want something like that? or: WARNING: Coffee is served HOT! [0] -- Ethan Benson http://www.alaska.net/~erbenson/ [0] for those who don't remember there was a case some years ago where a woman sued McDonalds after she spilled a cup of thier coffee in her lap and as a result was burned, her argument was that she didn't know coffee was hot. This is why to this day McDonalds' coffee cups have a warning printed all around them saying: WARNING COFFEE IS HOT!! -- at least in the lawsuit happy US. pgp96T2Cgw8q5.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 11:39:36PM -0700, Jacob Meuser wrote: I think it is quite fitting. i think is a 21st century varient of Godwin's law developing. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4AnOA3mFuw.pgp Description: PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 12:40:11AM -0700, Jacob Meuser wrote: that quote is pure marketing. Marketing? OpenBSD has about as much of an adversising dept as does Debian. None. that quote is still marketing, its backed up by excuses and lawyerly nitpicking, not real fact. And so the default install was not vulnerable to remote attacks. Like any other OS, you must update when updates are available. wrong. default install of all versions of OpenBSD prior to 2.7 WERE vulnerable because they turned on ftpd by default in the default install. the only reason they maintain that absurd `4 years without a root hole' is because they narrowly obsoleted 2.6 with 2.7 before that hole was discovered. like i said: lawyerly nitpicking. Exactly. The claim is that there is no REMOTE exploit. and local exploits don't matter? exactly the response i expect from a marketing person. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHxdeRowuRT.pgp Description: PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 01:37:29AM -0700, Jacob Meuser wrote: For the last time: I am saying that apt-get install should not immediately start a service, and it should not install the startup links in /etc/rc?.d. I could give a rats @$$ about what is Debian's base system. Those aren't installed with apt-get install anyway. I could give two $#1+$ about whether or not an OS is secure out of the box. This is not a question about OSes, it's a question about installing packages that install services. oh so your trying to sluff your own ignorance and incompetence onto debian because you installed a zillion services and didn't know what they did thus opening lots of `security holes'. yeah whatever. what part of `don't install the service if you don't need it/don't know how to configure it' don't you understand? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpDoqBbOgsU2.pgp Description: PGP signature
Re: red worm amusement
On Sun, Jul 22, 2001 at 07:11:04PM +1000, CaT wrote: On Sun, Jul 22, 2001 at 02:08:36AM -0700, Jacob Meuser wrote: I mentioned that OpenBSD has a policy of not starting services by default. Ethan Benson went off on how OpenBSD is rubbish. As no i said the claim that OpenBSD starts no services was rubbish. NOT that openbsd was rubbish. an OpenBSD user, I felt I should point out that he was the one full of rubbish. I really don't care whether people think it's your the own who is full of it Jacob. If you only wanted to talk about apt-get you should've stuck to it. yup. a good idea or not. I just wish they'd discuss the issue I'm talking about. I mean really, Ethan claimed I never installed OpenBSD. How could he have ever known whether or not that is true? Someone called ME a troll!?!?!?!?! because you (Jacob) made it quite clear you don't know anything about OpenBSD by making claims about it which are not true at all. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpxgMeBD0ZRm.pgp Description: PGP signature
Re: red worm amusement
On Fri, Jul 20, 2001 at 07:52:26PM -0700, Tim Uckun wrote: You really can not blame people for not hiring expensive unix sysadmins and letting some semi competent windows user run the NT network. oh? and whyever not? its this blatent irreponsibilty that we have such a mess security wise on the internet today. that is sort of like saying `you really cannot blame people for not hiring expensive archetectural engineers and letting some semi competant carpenter design your 10 story office building' -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 02:00:48PM -0700, Jacob Meuser wrote: On Sat, Jul 21, 2001 at 12:09:07AM -0800, Ethan Benson wrote: On Fri, Jul 20, 2001 at 07:52:26PM -0700, Tim Uckun wrote: You really can not blame people for not hiring expensive unix sysadmins and letting some semi competent windows user run the NT network. oh? and whyever not? its this blatent irreponsibilty that we have such a mess security wise on the internet today. Blatant irresponsibility, hmmm ... Perhaps Debian should follow the example of OpenBSD, and not start possibly dangerous services by default. It's really easy to install Debian and have all kinds of services running immediately. I doubt everyone who is running servers on Debain (by choosing to do so during the 'oh so easy' installation) really knows what they're doing. if you install a service its expected you want to run it, so if you don't need it don't install it. that said nfs-common, nfs-kernel-server, portmap, telnetd, fingerd, pidentd are all priority standard (in potato woody downgraded telnetd, and fingerd). this means they will be installed by default unless you skip tasksel/dselect, or explicitly set them to a deinstall state. nfs-kernel-server won't start unless there is an export in /etc/exports though, if that file is empty or all comments the initscript will simply exit without doing anything. im not sure why, or if its feasible for nfs-common to do something similar... telnetd and fingerd are good to see gone. it would be nice if nfs-common's initscript could tell whether it needs to run or not, like the nfs-server one does.. portmap is of course fine since its totally secure (see list archives). last i used OpenBSD (2.6) it started portmap and identd by default at the very least, maybe fingerd too i don't remember for sure. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 03:26:17PM -0700, Tim Uckun wrote: Well I thought I answered this question. Because Microsoft claims that you don't need them. They promise that their servers are easy to set up and maintain by normal people. When your CIO goes to shop around for a product and makes his cost analysis he does not add the cost of the sysadmin to the NT column. Microsoft told him that it was not needed and that it's a useless expense. I suppose CIO could be blamed for actually believing what MS says but let's face it most people don't realize that an MS executive will get fired if they don't lie to ten people by noon. there is a word to describe this: fraud. In a nutshell. The CIO bought a product and used it as advertised. It's really not the fault of the CIO that the product when used as advertised is faulty. The irresponsibility rests with MS who advertises stable, secure and high performance operating systems which don't need sysadmins to run. this is called `false advertising' and last i checked it was illegal in the United States. then again after all of these years i think ill bring up another timeless quote: fool me once, shame on you, fool me twice shame on me -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 06:27:00PM -0700, Jacob Meuser wrote: last i used OpenBSD (2.6) it started portmap and identd by default at the very least, maybe fingerd too i don't remember for sure. The difference is, those were not exploitable. oh? and why not? don't believe OpenBSD's hype about being the apex of computer and code security just because they have done auditing, they still miss A LOT. thier audited ftpd had a remote root hole recently. thier KERNEL also had a local root hole in it that was just fixed. I think a lot of people are just curious, and they install things they don't need, or really have any idea of what it does. The only reason they are able to get it to run is because it's easy. They may not have any idea that /etc/rc?.d exists. They very well may not expect it to be running the next time they reboot. well people need to learn. you can't treat computers like toasters anymore. deal with it. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 07:52:02PM -0700, Jacob Meuser wrote: Still not the point. I'm talking about services being enabled, either i don't think you know what your point is. i pointed out that openbsd starts portmap by default, along with identd and you reply with `but they are not exploitable' which is rubbish of course. go annoy someone else. i can change nothing in debian, i am not a debian developer, go annoy one of them. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Fri, Jul 20, 2001 at 07:52:26PM -0700, Tim Uckun wrote: You really can not blame people for not hiring expensive unix sysadmins and letting some semi competent windows user run the NT network. oh? and whyever not? its this blatent irreponsibilty that we have such a mess security wise on the internet today. that is sort of like saying `you really cannot blame people for not hiring expensive archetectural engineers and letting some semi competant carpenter design your 10 story office building' -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZZIRyuX72X.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 02:00:48PM -0700, Jacob Meuser wrote: On Sat, Jul 21, 2001 at 12:09:07AM -0800, Ethan Benson wrote: On Fri, Jul 20, 2001 at 07:52:26PM -0700, Tim Uckun wrote: You really can not blame people for not hiring expensive unix sysadmins and letting some semi competent windows user run the NT network. oh? and whyever not? its this blatent irreponsibilty that we have such a mess security wise on the internet today. Blatant irresponsibility, hmmm ... Perhaps Debian should follow the example of OpenBSD, and not start possibly dangerous services by default. It's really easy to install Debian and have all kinds of services running immediately. I doubt everyone who is running servers on Debain (by choosing to do so during the 'oh so easy' installation) really knows what they're doing. if you install a service its expected you want to run it, so if you don't need it don't install it. that said nfs-common, nfs-kernel-server, portmap, telnetd, fingerd, pidentd are all priority standard (in potato woody downgraded telnetd, and fingerd). this means they will be installed by default unless you skip tasksel/dselect, or explicitly set them to a deinstall state. nfs-kernel-server won't start unless there is an export in /etc/exports though, if that file is empty or all comments the initscript will simply exit without doing anything. im not sure why, or if its feasible for nfs-common to do something similar... telnetd and fingerd are good to see gone. it would be nice if nfs-common's initscript could tell whether it needs to run or not, like the nfs-server one does.. portmap is of course fine since its totally secure (see list archives). last i used OpenBSD (2.6) it started portmap and identd by default at the very least, maybe fingerd too i don't remember for sure. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpi8Unk02ALq.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 03:26:17PM -0700, Tim Uckun wrote: Well I thought I answered this question. Because Microsoft claims that you don't need them. They promise that their servers are easy to set up and maintain by normal people. When your CIO goes to shop around for a product and makes his cost analysis he does not add the cost of the sysadmin to the NT column. Microsoft told him that it was not needed and that it's a useless expense. I suppose CIO could be blamed for actually believing what MS says but let's face it most people don't realize that an MS executive will get fired if they don't lie to ten people by noon. there is a word to describe this: fraud. In a nutshell. The CIO bought a product and used it as advertised. It's really not the fault of the CIO that the product when used as advertised is faulty. The irresponsibility rests with MS who advertises stable, secure and high performance operating systems which don't need sysadmins to run. this is called `false advertising' and last i checked it was illegal in the United States. then again after all of these years i think ill bring up another timeless quote: fool me once, shame on you, fool me twice shame on me -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4aYTtRhbva.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 06:27:00PM -0700, Jacob Meuser wrote: last i used OpenBSD (2.6) it started portmap and identd by default at the very least, maybe fingerd too i don't remember for sure. The difference is, those were not exploitable. oh? and why not? don't believe OpenBSD's hype about being the apex of computer and code security just because they have done auditing, they still miss A LOT. thier audited ftpd had a remote root hole recently. thier KERNEL also had a local root hole in it that was just fixed. I think a lot of people are just curious, and they install things they don't need, or really have any idea of what it does. The only reason they are able to get it to run is because it's easy. They may not have any idea that /etc/rc?.d exists. They very well may not expect it to be running the next time they reboot. well people need to learn. you can't treat computers like toasters anymore. deal with it. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIC130b3ULJ.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 07:52:02PM -0700, Jacob Meuser wrote: Still not the point. I'm talking about services being enabled, either i don't think you know what your point is. i pointed out that openbsd starts portmap by default, along with identd and you reply with `but they are not exploitable' which is rubbish of course. go annoy someone else. i can change nothing in debian, i am not a debian developer, go annoy one of them. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpUsKNsqyfYb.pgp Description: PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 02:10:42AM +0200, Wichert Akkerman wrote: For amusement I checked the web logs for a few debian machines to see if they had some red worm attempts. Seems we've been probed a fair bit: 16 times on www.spi-inc.org, 22 on non-us.debian.org and 18 on www.debian.org. Almost all attempts were made on July 19. Aren't we glad we all run Linux? :) otoh i get nearly a dozen ftp and dns connection attempts a week at a minimum, no doubt looking for vulnerable versions of bind and wu-ftpd. also a dozen portmap connection attempts per day, no doubt looking for vulnerable rpc.statd. incompetant `morons with root password' (i won't call them sysadmins) who won't install security updates are really the worse problem. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: red worm amusement
On Sat, Jul 21, 2001 at 02:10:42AM +0200, Wichert Akkerman wrote: For amusement I checked the web logs for a few debian machines to see if they had some red worm attempts. Seems we've been probed a fair bit: 16 times on www.spi-inc.org, 22 on non-us.debian.org and 18 on www.debian.org. Almost all attempts were made on July 19. Aren't we glad we all run Linux? :) otoh i get nearly a dozen ftp and dns connection attempts a week at a minimum, no doubt looking for vulnerable versions of bind and wu-ftpd. also a dozen portmap connection attempts per day, no doubt looking for vulnerable rpc.statd. incompetant `morons with root password' (i won't call them sysadmins) who won't install security updates are really the worse problem. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpDDr9QPRj2q.pgp Description: PGP signature
Re: shared root account
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote: On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: nice to know pam_pwdfile gained md5 support, iirc it only did the anchient crappy crypt before.. now there just needs to be a passwd command to work with this... htpasswd doesn't provide proper restrictions and authentication. (for other uses then sudo passwords). whats really needed is a passwd command that behaves exactly the same as passwd, only with alternate passwd files. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
