Re: Clear screan question
On Sat, Jan 27, 2001 at 03:39:02PM +0100, Sune Kirkeby wrote: > > I don't know how or why, but it does _not_ clear the scroll-back buffer > on my console, "chvt 63 ; reset -Q ; chvt 1" does though. you don't need the reset -Q there. the simple act of changing VCs clears the scrollback history. the scrollback history is being kept by the kernel, its not known to the various terminal software. shift page-up is not part of normal terminals. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpRbBzdMN7mL.pgp Description: PGP signature
Re: Clear screan question
On Sat, Jan 27, 2001 at 08:53:53AM -0600, wes schreiner wrote: > A winner! OK, it flashes if vt 63 is in use, but otherwise it's great. yeah but who actually uses that many terminals ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpjeqEfQCavQ.pgp Description: PGP signature
Re: Clear screan question
On Sat, Jan 27, 2001 at 03:39:02PM +0100, Sune Kirkeby wrote: > > I don't know how or why, but it does _not_ clear the scroll-back buffer > on my console, "chvt 63 ; reset -Q ; chvt 1" does though. you don't need the reset -Q there. the simple act of changing VCs clears the scrollback history. the scrollback history is being kept by the kernel, its not known to the various terminal software. shift page-up is not part of normal terminals. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Clear screan question
On Sat, Jan 27, 2001 at 08:53:53AM -0600, wes schreiner wrote: > A winner! OK, it flashes if vt 63 is in use, but otherwise it's great. yeah but who actually uses that many terminals ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Clear screan question
On Sat, Jan 27, 2001 at 07:37:59AM -0600, wes schreiner wrote:
>
> # ~/.bash_logout: executed by bash(1) when login shell exits.
> # when leaving the console clear the screen to increase privacy
> case "`tty`" in
> /dev/tty[0-9]) echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L
> clear
>
> Those ^L are real control-L's, not shift-6, shift-L. I'd still like to
> see a cleaner way to clear the CONSOLE scroll-back. All of the
> suggestions so far (clear, reset -Q, ESC[2J ESC[0;0H in /etc/issue) just
> clear the immediately visible screen, not the console scroll-back.
how about:
case "$(tty)" in
/dev/tty[0-9])
t=$(v=`tty` ; echo ${v##*ty})
clear
chvt 63; chvt "$t"
;;
*)
;;
esac
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpcoaxwsAnIB.pgp
Description: PGP signature
Re: Clear screan question
On Sat, Jan 27, 2001 at 07:37:59AM -0600, wes schreiner wrote:
>
> # ~/.bash_logout: executed by bash(1) when login shell exits.
> # when leaving the console clear the screen to increase privacy
> case "`tty`" in
> /dev/tty[0-9]) echo ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L\
> ^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L^L
> clear
>
> Those ^L are real control-L's, not shift-6, shift-L. I'd still like to
> see a cleaner way to clear the CONSOLE scroll-back. All of the
> suggestions so far (clear, reset -Q, ESC[2J ESC[0;0H in /etc/issue) just
> clear the immediately visible screen, not the console scroll-back.
how about:
case "$(tty)" in
/dev/tty[0-9])
t=$(v=`tty` ; echo ${v##*ty})
clear
chvt 63; chvt "$t"
;;
*)
;;
esac
--
Ethan Benson
http://www.alaska.net/~erbenson/
PGP signature
Re: chroot (was: checking security logs)
On Tue, Jan 23, 2001 at 10:04:22AM -0600, David Duffey wrote: > > off topic: I wonder how easy it would be to make debian packages setup into > a chrooted environment, right now I do everything by hand (which tends to > leave the chrooted evironment out-of-date when upgrading packages. build the chroot in the initscript itself, thats what i do for bind. that way when the debian package is upgraded and bind is restarted the new binaries are copied into the chroot before the daemon is started. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp5HgdgqFNBq.pgp Description: PGP signature
Re: chroot (was: checking security logs)
On Tue, Jan 23, 2001 at 10:04:22AM -0600, David Duffey wrote: > > off topic: I wonder how easy it would be to make debian packages setup into > a chrooted environment, right now I do everything by hand (which tends to > leave the chrooted evironment out-of-date when upgrading packages. build the chroot in the initscript itself, thats what i do for bind. that way when the debian package is upgraded and bind is restarted the new binaries are copied into the chroot before the daemon is started. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: lprng
On Mon, Jan 15, 2001 at 10:10:08AM +0100, V. Achiaga wrote: > > > Hey, > > What u mean debian-specific patch? > > I only want to mean a patch including the patch.diff file, or an > official debian package (.deb file) if debian is vulnerable then a updated package should indeed be placed in security.debian.org > > > I know there's a debian package of lprng, but I don't know if the patch > > > you're talking about is applied to this package, I guess you should check > > > the changelog to find out. > > At the moment, the patch isnt applied... So I think that debian is > vulnerable. i am not certain that it is, from the original post to BugTraq telnetting to the printer port and entering several %s would cause the daemon to segfault, this does not occur on debian. also i tried an exploit (targetted at RH7) which had various bruteforce options against debian and it failed. does not necessarily mean its not vulnerable of course... a couple things i noticed: lprng does *NO* logging that i can see, syslog seems to direct lpr logs to /var/log/lpr.log which is empty on my system no matter what i do. also from the lprng changelog.Debian.gz: lprng (3.6.12-7) stable; urgency=high * SECURITY FIXES!! * syslog() overflow bug fixed * getttext NLSPATH security bug fixed. * spool_file_perms security bug fixed. * Added setuid Linux bug work-around. -- Craig Small <[EMAIL PROTECTED]> Sun, 15 Oct 2000 15:42:02 -0500 as i understand it the syslog() problem in this case is a format string so that might be something different. as far as i can tell debian's lprng never logs anything so perhaps never calls syslog(). i wish debian released security unadvisories when thier package is not vulnerable to a certain bug like this... -- Ethan Benson http://www.alaska.net/~erbenson/ pgpAlDI35fBIk.pgp Description: PGP signature
Re: lprng
On Mon, Jan 15, 2001 at 10:10:08AM +0100, V. Achiaga wrote: > > > Hey, > > What u mean debian-specific patch? > > I only want to mean a patch including the patch.diff file, or an > official debian package (.deb file) if debian is vulnerable then a updated package should indeed be placed in security.debian.org > > > I know there's a debian package of lprng, but I don't know if the patch > > > you're talking about is applied to this package, I guess you should check > > > the changelog to find out. > > At the moment, the patch isnt applied... So I think that debian is > vulnerable. i am not certain that it is, from the original post to BugTraq telnetting to the printer port and entering several %s would cause the daemon to segfault, this does not occur on debian. also i tried an exploit (targetted at RH7) which had various bruteforce options against debian and it failed. does not necessarily mean its not vulnerable of course... a couple things i noticed: lprng does *NO* logging that i can see, syslog seems to direct lpr logs to /var/log/lpr.log which is empty on my system no matter what i do. also from the lprng changelog.Debian.gz: lprng (3.6.12-7) stable; urgency=high * SECURITY FIXES!! * syslog() overflow bug fixed * getttext NLSPATH security bug fixed. * spool_file_perms security bug fixed. * Added setuid Linux bug work-around. -- Craig Small <[EMAIL PROTECTED]> Sun, 15 Oct 2000 15:42:02 -0500 as i understand it the syslog() problem in this case is a format string so that might be something different. as far as i can tell debian's lprng never logs anything so perhaps never calls syslog(). i wish debian released security unadvisories when thier package is not vulnerable to a certain bug like this... -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Debian audititing tool?
On Wed, Dec 27, 2000 at 11:12:28AM +0100, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. you still need to fix your Mail-Followup-To to reflect this as well. its really quite simple just change `lists' to `subscribe' in your ~/.muttrc. i know your using lists since mutt does not even add a Mail-Followup-To otherwise. the only difference between lists and subscribe is the former requests you be CCed, while the latter does not. right now your mutt configuration causes mutt list reply to CC you. this is mutt in potato r2. i would suggest fixing it if you really don't want CCs because your going to get them regardless of that Mail-Copies-To. /me manually has to remove Christian's address from the CC line. and won't do it next time. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpQHgZ6UiIoG.pgp Description: PGP signature
Re: Debian audititing tool?
On Wed, Dec 27, 2000 at 11:12:28AM +0100, Christian Kurz wrote: > > You probably misconfigured your mutt. > > No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has > the correct "Mail-Copies-To: never", which means that I don't want any > copies of the answers. you still need to fix your Mail-Followup-To to reflect this as well. its really quite simple just change `lists' to `subscribe' in your ~/.muttrc. i know your using lists since mutt does not even add a Mail-Followup-To otherwise. the only difference between lists and subscribe is the former requests you be CCed, while the latter does not. right now your mutt configuration causes mutt list reply to CC you. this is mutt in potato r2. i would suggest fixing it if you really don't want CCs because your going to get them regardless of that Mail-Copies-To. /me manually has to remove Christian's address from the CC line. and won't do it next time. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > That's why you run the checker from a known-good floppy or CD. The bogus > kernel can't protect itself if it isn't running :) don't be so sure, is the BIOS or firmware on your computer flashable? if so an attacker could replace the firmware/BIOS itself to ensure later trojans are installed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp7XSWWLUylx.pgp Description: PGP signature
Re: Debian audititing tool?
On Fri, Dec 22, 2000 at 05:54:55PM -0400, Peter Cordes wrote: > > That's why you run the checker from a known-good floppy or CD. The bogus > kernel can't protect itself if it isn't running :) don't be so sure, is the BIOS or firmware on your computer flashable? if so an attacker could replace the firmware/BIOS itself to ensure later trojans are installed. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: /dev/fb* permissions, local DoS
i don't know why my message was reposted, it sure wasn't me, from looking at the headers its ya broken hong kong news gateway or something. this has already been delt with, the solution was MADEDEV now creates the /dev/fb* devices mode 620 root.video. On Mon, Dec 18, 2000 at 12:19:45PM +1100, Chris Leishman wrote: > On Mon, Dec 18, 2000 at 01:13:42AM +0100, Michel Dänzer wrote: > > > > > Only all apps which need a framebuffer device to work... > > Well, only the person on the console can run those apps anyway and thus should > be the only one with access to the devices. > > > > > > > > Doesn't crash my i386 (riva tnt2, XF4) - but does put pretty colors over > > > the top 1/3 of the screen before cat exits with "write error: No space > > > left > > > on device". > > > > Yep, I think the crash is a bug in the framebuffer device, just like the > > other > > problem where even reading from /dev/fb* caused a crash with atyfb IIRC. > > > > It's still a problem without the crash since any local user can overwrite the > console screen with garbage. > > Regards, > > Chris > -- Ethan Benson http://www.alaska.net/~erbenson/ pgpK1nYBB6mID.pgp Description: PGP signature
Re: /dev/fb* permissions, local DoS
i don't know why my message was reposted, it sure wasn't me, from looking at the headers its ya broken hong kong news gateway or something. this has already been delt with, the solution was MADEDEV now creates the /dev/fb* devices mode 620 root.video. On Mon, Dec 18, 2000 at 12:19:45PM +1100, Chris Leishman wrote: > On Mon, Dec 18, 2000 at 01:13:42AM +0100, Michel Dänzer wrote: > > > > > Only all apps which need a framebuffer device to work... > > Well, only the person on the console can run those apps anyway and thus should > be the only one with access to the devices. > > > > > > > > Doesn't crash my i386 (riva tnt2, XF4) - but does put pretty colors over > > > the top 1/3 of the screen before cat exits with "write error: No space left > > > on device". > > > > Yep, I think the crash is a bug in the framebuffer device, just like the other > > problem where even reading from /dev/fb* caused a crash with atyfb IIRC. > > > > It's still a problem without the crash since any local user can overwrite the > console screen with garbage. > > Regards, > > Chris > -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Processes
On Sat, Dec 02, 2000 at 02:49:22PM +0100, Joakim Friberg wrote: > Hello! > > Do any one have an example of a script/deamon fo eliminating unecessary > processes, like if an user starts to clone prosesses. man slay ;-) (actually slay is a pretty convenient way to kill off an obnoxious luser who is screwing around) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp2Dqb3lLBXf.pgp Description: PGP signature
Re: Processes
On Sat, Dec 02, 2000 at 02:49:22PM +0100, Joakim Friberg wrote: > Hello! > > Do any one have an example of a script/deamon fo eliminating unecessary > processes, like if an user starts to clone prosesses. man slay ;-) (actually slay is a pretty convenient way to kill off an obnoxious luser who is screwing around) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Problems with root on network clients
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote: > erbenson> NFS is insecure, deal with it. > > Such as use something besides NFS that is secure; the options are thin > and immature, but you may still look around because I have a feeling > there may be a good match, if you're willing to sacrafice admin time > to the task. For instance, I'm curious if CODA has played this trick. > They talk about distribution, security, etc. Plus, administration of > local disk caches could become really easy with CODA -- 4GB disk > cache, now that's nice; it's as if you only really have one machine in > some administrative senses. Now, somebody tell me if I'm wrong. > There is a whole page of Linux filesystems besides EXT2 and NFS out > there someplace. Find it and take a good research if you have the > time. note that i don't fully understand how coda works, but the impression i get is you need a very large ammount of LOCAL disk space to hold coda's cache/offline storage. this to me defeats the purpose of a network filesystem in a large number of cases (i have several machines with not much disk, and one with lots of space, thus i export /home) coda is also very non-trivial to administer and maintain from what i can see. its just not designed with small setups in mind. NFS is a very simple and convenient network filesystem, it just lacks any attempt at a security infrastructure. > Once you make yourself vulnerable to physical host takeover and make > yourself secure from that, you have definitely got yourself a few > rungs up. Otherwise, another thing I can suggest is hide the floppies > (I mean, take them out). Floppies are a mess anyway, and we shouldn't > need them. This does not make it impossible to install a new floppy. > You could scratch out the IDE leads to the floppy cable, and make the > machine less valuable. they can always plug in a new IDE disk which they can boot from, have root, mount NFS... they could also simply bring in a laptop, see what IP address the desktop machine has, configure thier laptop with it and switch the network cable from the desktop to the laptop taking over the IP address. all NFS cares about is the source IP, not very strong...) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpomelRgoOyo.pgp Description: PGP signature
Re: Problems with root on network clients
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote: > erbenson> NFS is insecure, deal with it. > > Such as use something besides NFS that is secure; the options are thin > and immature, but you may still look around because I have a feeling > there may be a good match, if you're willing to sacrafice admin time > to the task. For instance, I'm curious if CODA has played this trick. > They talk about distribution, security, etc. Plus, administration of > local disk caches could become really easy with CODA -- 4GB disk > cache, now that's nice; it's as if you only really have one machine in > some administrative senses. Now, somebody tell me if I'm wrong. > There is a whole page of Linux filesystems besides EXT2 and NFS out > there someplace. Find it and take a good research if you have the > time. note that i don't fully understand how coda works, but the impression i get is you need a very large ammount of LOCAL disk space to hold coda's cache/offline storage. this to me defeats the purpose of a network filesystem in a large number of cases (i have several machines with not much disk, and one with lots of space, thus i export /home) coda is also very non-trivial to administer and maintain from what i can see. its just not designed with small setups in mind. NFS is a very simple and convenient network filesystem, it just lacks any attempt at a security infrastructure. > Once you make yourself vulnerable to physical host takeover and make > yourself secure from that, you have definitely got yourself a few > rungs up. Otherwise, another thing I can suggest is hide the floppies > (I mean, take them out). Floppies are a mess anyway, and we shouldn't > need them. This does not make it impossible to install a new floppy. > You could scratch out the IDE leads to the floppy cable, and make the > machine less valuable. they can always plug in a new IDE disk which they can boot from, have root, mount NFS... they could also simply bring in a laptop, see what IP address the desktop machine has, configure thier laptop with it and switch the network cable from the desktop to the laptop taking over the IP address. all NFS cares about is the source IP, not very strong...) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Problems with root on network clients
On Thu, Nov 23, 2000 at 02:39:54PM +0100, Philippe Barnetche wrote: > Hi, > > you can change the PAM attributes of "su", avoiding local root to get user > account access. Of course, if your /etc is local, you'll still have the > problem. that would be very weak, if root could write to anywhere and compilers are available a very simple program to setuid(1000) would replace su quite easily. i have read about secure RPC which seems to somewhat solve NFS issues, but i think its not supported on linux. unfortunatly at this point it really boils down to: NFS is insecure, deal with it. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpyM3krRNCOC.pgp Description: PGP signature
Re: Problems with root on network clients
On Thu, Nov 23, 2000 at 02:39:54PM +0100, Philippe Barnetche wrote: > Hi, > > you can change the PAM attributes of "su", avoiding local root to get user > account access. Of course, if your /etc is local, you'll still have the > problem. that would be very weak, if root could write to anywhere and compilers are available a very simple program to setuid(1000) would replace su quite easily. i have read about secure RPC which seems to somewhat solve NFS issues, but i think its not supported on linux. unfortunatly at this point it really boils down to: NFS is insecure, deal with it. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 09:28:29PM +0100, Michel Dänzer wrote: > Ethan Benson wrote: > > > > hour:/home/kr0n# ls -ls /dev/fb0 > > > 0 crw--w--w-1 root tty 29, 0 Jul 5 14:44 /dev/fb0 > > > > apparently writing random garbage into the fb devices is not supposed > > to cause a kernel panic, that seems to be a bug in the framebuffer > > driver in my kernel. (or perhaps all 2.2 kernels with aty128fb) i > > still think it would be more appropriate to have these permissions set > > to 620 root.video. > > root.tty makes a lot of sense to me, too. really? why? group tty is pretty much just for write and talk, which have no relevence to framebuffer devices. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpzd4S4u3mD6.pgp Description: PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 09:28:29PM +0100, Michel Dänzer wrote: > Ethan Benson wrote: > > > > hour:/home/kr0n# ls -ls /dev/fb0 > > > 0 crw--w--w-1 root tty 29, 0 Jul 5 14:44 /dev/fb0 > > > > apparently writing random garbage into the fb devices is not supposed > > to cause a kernel panic, that seems to be a bug in the framebuffer > > driver in my kernel. (or perhaps all 2.2 kernels with aty128fb) i > > still think it would be more appropriate to have these permissions set > > to 620 root.video. > > root.tty makes a lot of sense to me, too. really? why? group tty is pretty much just for write and talk, which have no relevence to framebuffer devices. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: strange file
On Mon, Nov 20, 2000 at 03:50:29PM +0100, Virginie-ML wrote: > > I don't :) > Especially when I don't use esound... do you have it installed? gnome programs love to start all kinds of little daemons and such all on their own, esd is one of them. even if you don't use gnome as your desktop environment/windowmanger if you start almost any gnome program it will launch all sorts of other little things. that still does not explain how that file ended up in / though. do you run any gnome programs as root? (an evil practice IMO) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp3pI9rf1kzp.pgp Description: PGP signature
Re: task-unstable-security-updates?
On Mon, Nov 20, 2000 at 09:21:40AM -0500, Itai Zukerman wrote: > > Those who choose to run unstable choose to take upon themselves > > more responsibility/inconvenience, if they are unwilling to bear that > > burden they should not run unstable. > > To me this sounds like: > > Every single unstable user must track debian-security-announce. really even stable users should track d-s-a, especially if you run something other then x86 since occasionally security fixes don't get into other archs right away. > versus: > > One unstable user should track debian-security-announce, and do a > little bit of work to make every other unstable user's life much > easier. there is really more to it then that, fixed packages are usually just installed into unstable like any other update to unstable, this means the package very well may not get built for anything but x86. so if you run an intel box your probably going to be fine just tracking unstable, but if you run anything else, say a powerpc or a sparc you might have to get the source and build the package yourself. i had to do this very frequently when i tracked then unstable potato on my powerpc. so its not just making a task package its also making sure that the package is built for each and every archetecture debian supports, and making sure that gets installed in the archive along with the task package. this is what the security team currently does for stable (except there is no task package, other then security.debian.org). if someone wants to volunteer to serve all the functions the security team does for unstable im sure that would be welcome but i think its alot more work then you think it is. (disclaimer i am not a member of the security team or a debian developer, but judging by how annoyed they get by anything resembling nagging i will venture to say they quite busy and there is alot of work involved) > But tracking d-s-a isn't enough for unstable, since only (I believe) > security fixes for packages in stable are reported there. that is generally correct. this came up a while back when potato was unstable. however i think security fixes tend to start getting made when for frozen when its created. > Again, let me ask: Why is there no "security" bug tag? When a > security fix is released, we can then have (for stable, tracking > d-s-a): i don't know, i vaguely recall some comments about a security tag in the initial discussion on -devel but i didn't follow that thread terribly closely. check the archives, read the thread on bug tags. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpI82wIV6Yfj.pgp Description: PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 11:54:12AM -0200, Philipe Gaspar wrote: > this is some strange > > hour:/home/kr0n# cat /dev/urandom > /dev/fb0 > bash: /dev/fb0: No such device not really, it just means you don't have a framebuffer configured in your kernel. intel machines usually do not use a framebuffer (almost certainly not by default) however nearly all powerpc and sparc hardware require framebuffers. > hour:/home/kr0n# ls -ls /dev/fb0 > 0 crw--w--w-1 root tty 29, 0 Jul 5 14:44 /dev/fb0 apparently writing random garbage into the fb devices is not supposed to cause a kernel panic, that seems to be a bug in the framebuffer driver in my kernel. (or perhaps all 2.2 kernels with aty128fb) i still think it would be more appropriate to have these permissions set to 620 root.video. opinions? or should i file a wishlist bug against makedev? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpohzQeDOMIc.pgp Description: PGP signature
Re: task-unstable-security-updates?
On Mon, Nov 20, 2000 at 08:21:10AM -0500, Itai Zukerman wrote: > > The answer is just to watch one single list - debian-security-announce. > > That's what it's for :) > > I'm not sure I understand the reasoning here. If the answer is to > watch the debian-security-announce list, then what prevents someone > watching the list from maintaining the proposed virtual package? watching the security-announce list is done by the admin/user of the system, maintaining a virtual package is done by busy debian developers who have too much to do as it is. Those who choose to run unstable choose to take upon themselves more responsibility/inconvenience, if they are unwilling to bear that burden they should not run unstable. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJJinLzLk9Z.pgp Description: PGP signature
Re: strange file
On Mon, Nov 20, 2000 at 03:50:29PM +0100, Virginie-ML wrote: > > I don't :) > Especially when I don't use esound... do you have it installed? gnome programs love to start all kinds of little daemons and such all on their own, esd is one of them. even if you don't use gnome as your desktop environment/windowmanger if you start almost any gnome program it will launch all sorts of other little things. that still does not explain how that file ended up in / though. do you run any gnome programs as root? (an evil practice IMO) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: task-unstable-security-updates?
On Mon, Nov 20, 2000 at 09:21:40AM -0500, Itai Zukerman wrote: > > Those who choose to run unstable choose to take upon themselves > > more responsibility/inconvenience, if they are unwilling to bear that > > burden they should not run unstable. > > To me this sounds like: > > Every single unstable user must track debian-security-announce. really even stable users should track d-s-a, especially if you run something other then x86 since occasionally security fixes don't get into other archs right away. > versus: > > One unstable user should track debian-security-announce, and do a > little bit of work to make every other unstable user's life much > easier. there is really more to it then that, fixed packages are usually just installed into unstable like any other update to unstable, this means the package very well may not get built for anything but x86. so if you run an intel box your probably going to be fine just tracking unstable, but if you run anything else, say a powerpc or a sparc you might have to get the source and build the package yourself. i had to do this very frequently when i tracked then unstable potato on my powerpc. so its not just making a task package its also making sure that the package is built for each and every archetecture debian supports, and making sure that gets installed in the archive along with the task package. this is what the security team currently does for stable (except there is no task package, other then security.debian.org). if someone wants to volunteer to serve all the functions the security team does for unstable im sure that would be welcome but i think its alot more work then you think it is. (disclaimer i am not a member of the security team or a debian developer, but judging by how annoyed they get by anything resembling nagging i will venture to say they quite busy and there is alot of work involved) > But tracking d-s-a isn't enough for unstable, since only (I believe) > security fixes for packages in stable are reported there. that is generally correct. this came up a while back when potato was unstable. however i think security fixes tend to start getting made when for frozen when its created. > Again, let me ask: Why is there no "security" bug tag? When a > security fix is released, we can then have (for stable, tracking > d-s-a): i don't know, i vaguely recall some comments about a security tag in the initial discussion on -devel but i didn't follow that thread terribly closely. check the archives, read the thread on bug tags. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 11:54:12AM -0200, Philipe Gaspar wrote: > this is some strange > > hour:/home/kr0n# cat /dev/urandom > /dev/fb0 > bash: /dev/fb0: No such device not really, it just means you don't have a framebuffer configured in your kernel. intel machines usually do not use a framebuffer (almost certainly not by default) however nearly all powerpc and sparc hardware require framebuffers. > hour:/home/kr0n# ls -ls /dev/fb0 > 0 crw--w--w-1 root tty 29, 0 Jul 5 14:44 /dev/fb0 apparently writing random garbage into the fb devices is not supposed to cause a kernel panic, that seems to be a bug in the framebuffer driver in my kernel. (or perhaps all 2.2 kernels with aty128fb) i still think it would be more appropriate to have these permissions set to 620 root.video. opinions? or should i file a wishlist bug against makedev? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: task-unstable-security-updates?
On Mon, Nov 20, 2000 at 08:21:10AM -0500, Itai Zukerman wrote: > > The answer is just to watch one single list - debian-security-announce. > > That's what it's for :) > > I'm not sure I understand the reasoning here. If the answer is to > watch the debian-security-announce list, then what prevents someone > watching the list from maintaining the proposed virtual package? watching the security-announce list is done by the admin/user of the system, maintaining a virtual package is done by busy debian developers who have too much to do as it is. Those who choose to run unstable choose to take upon themselves more responsibility/inconvenience, if they are unwilling to bear that burden they should not run unstable. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 10:09:23AM +0100, Michel Dänzer wrote: > > So 0620 might be better, with /dev/fb in group video or a dedicated group. that seems more reasonable. > This is on a SuSE 6.4 system BTW: > > crw-rw 1 root video 29, 0 Mar 11 2000 /dev/fb0 this is broken IMO, it allows all members of group video to grab a copy of the current framebuffer contents. 620 is safer. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpA38sVKhT3h.pgp Description: PGP signature
Re: /dev/fb* permissions, local DoS
On Mon, Nov 20, 2000 at 10:09:23AM +0100, Michel Dänzer wrote: > > So 0620 might be better, with /dev/fb in group video or a dedicated group. that seems more reasonable. > This is on a SuSE 6.4 system BTW: > > crw-rw 1 root video 29, 0 Mar 11 2000 /dev/fb0 this is broken IMO, it allows all members of group video to grab a copy of the current framebuffer contents. 620 is safer. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
/dev/fb* permissions, local DoS
does anyone know why debian has /dev/fb* with 622 permissions? the reason i ask is there is a pretty nasty security problem with this, try the following: cat /dev/urandom > /dev/fb0 on my system i get a instant kernel panic (2.2.17 from ftp.kernel.org). since the framebuffer devices are world writable anyone with a shell account can crash the system, not nice. (i have a blue G3 using aty128fb) what is broken by setting the permissions on all the framebuffer devices to 0600 ? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpcR5uVdP2Qh.pgp Description: PGP signature
/dev/fb* permissions, local DoS
does anyone know why debian has /dev/fb* with 622 permissions? the reason i ask is there is a pretty nasty security problem with this, try the following: cat /dev/urandom > /dev/fb0 on my system i get a instant kernel panic (2.2.17 from ftp.kernel.org). since the framebuffer devices are world writable anyone with a shell account can crash the system, not nice. (i have a blue G3 using aty128fb) what is broken by setting the permissions on all the framebuffer devices to 0600 ? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: vixie cron... (fwd)
On Fri, Nov 17, 2000 at 07:54:26AM -0600, An Thi-Nguyen Le wrote: > On Fri, Nov 17, 2000 at 03:46:19AM -0900, Ethan Benson typed: > } On Fri, Nov 17, 2000 at 12:36:54PM +, thomas lakofski wrote: > } > fyi -- i've not tried it. > } > } i have, it does not work, i tried several different variations and > } failed to create any files in /var/spool/cron. > } > } i do not believe debian is vulnerable. > > Wrong, we *are* vulnerable. Take a look /var/spool/cron/crontabs > instead. ah, your right, however this is not exploitable since /var/spool/cron/crontabs is mode 700. still should be fixed though. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpUpcO28Fy28.pgp Description: PGP signature
Re: vixie cron... (fwd)
On Fri, Nov 17, 2000 at 07:54:26AM -0600, An Thi-Nguyen Le wrote: > On Fri, Nov 17, 2000 at 03:46:19AM -0900, Ethan Benson typed: > } On Fri, Nov 17, 2000 at 12:36:54PM +, thomas lakofski wrote: > } > fyi -- i've not tried it. > } > } i have, it does not work, i tried several different variations and > } failed to create any files in /var/spool/cron. > } > } i do not believe debian is vulnerable. > > Wrong, we *are* vulnerable. Take a look /var/spool/cron/crontabs > instead. ah, your right, however this is not exploitable since /var/spool/cron/crontabs is mode 700. still should be fixed though. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: vixie cron... (fwd)
On Fri, Nov 17, 2000 at 12:36:54PM +, thomas lakofski wrote: > fyi -- i've not tried it. i have, it does not work, i tried several different variations and failed to create any files in /var/spool/cron. i do not believe debian is vulnerable. > -- Forwarded message -- > From: Michal Zalewski <[EMAIL PROTECTED]> > To: BUGTRAQ@SECURITYFOCUS.COM > Date: Fri, 17 Nov 2000 05:41:32 +0100 > Subject: vixie cron... [snip] -- Ethan Benson http://www.alaska.net/~erbenson/ pgpbnJ1Xm7wnV.pgp Description: PGP signature
Re: vixie cron... (fwd)
On Fri, Nov 17, 2000 at 12:36:54PM +, thomas lakofski wrote: > fyi -- i've not tried it. i have, it does not work, i tried several different variations and failed to create any files in /var/spool/cron. i do not believe debian is vulnerable. > -- Forwarded message -- > From: Michal Zalewski <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Fri, 17 Nov 2000 05:41:32 +0100 > Subject: vixie cron... [snip] -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: restricted bash (rbash)
On Thu, Nov 16, 2000 at 09:02:33AM -0200, Pedro Zorzenon Neto wrote: > I forgot one thing about all this... > > All about the restricted bash could be useless if you forget to > lock the ftp acount of the restricted users. > > You can avoid them to edit and create shell scripts inside their > telnet session, but if you forget to lock their ftp session ... > they could put scripts in their directory and execute them by telnet... for restricted shells to be effective the user must not have write permission to there home directory or thier ~/.bash* files they also must not have write permission to the directory in thier PATH. one other thing you will need to do, is create ~/.ssh/environment with the following: PATH=/what/ever/restricted otherwise a simply ssh localhost /bin/bash will bypass the whole thing. ssh sets a default PATH when you login with a command name (since it does not run your shell from /etc/passwd nor parse the ~/.dotfiles) the ~/.ssh directory and env file must of course not be writable by the user. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpi0pF3wh7wi.pgp Description: PGP signature
Re: openssh configuration
On Thu, Nov 16, 2000 at 03:20:24PM +0800, Lincoln Leung wrote: > > hi, > > i've just installed openssh-2.3.0p1 on my Debian 2.2 but failed to login > using users' passwords. Password authentication failed all the time and it > prompted "Permission Denied" on the command line. a message, "Failed > password for [user] from .." was logged in auth.log. but i'm sure the > password is correct. i wonder if the configuration for PAM is incorrect. > Below is the content of /etc/pam.d/sshd: ^^ thats supposed to be /etc/pam.d/ssh unless they changed it again... when potato was unstable openssh kept changing back and forth from ssh to sshd, the final is /etc/pam.d/ssh. this would get me since i have pam_deny in my /etc/pam.d/other. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpSFJslf0k1v.pgp Description: PGP signature
Re: restricted bash (rbash)
On Thu, Nov 16, 2000 at 09:02:33AM -0200, Pedro Zorzenon Neto wrote: > I forgot one thing about all this... > > All about the restricted bash could be useless if you forget to > lock the ftp acount of the restricted users. > > You can avoid them to edit and create shell scripts inside their > telnet session, but if you forget to lock their ftp session ... > they could put scripts in their directory and execute them by telnet... for restricted shells to be effective the user must not have write permission to there home directory or thier ~/.bash* files they also must not have write permission to the directory in thier PATH. one other thing you will need to do, is create ~/.ssh/environment with the following: PATH=/what/ever/restricted otherwise a simply ssh localhost /bin/bash will bypass the whole thing. ssh sets a default PATH when you login with a command name (since it does not run your shell from /etc/passwd nor parse the ~/.dotfiles) the ~/.ssh directory and env file must of course not be writable by the user. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: openssh configuration
On Thu, Nov 16, 2000 at 03:20:24PM +0800, Lincoln Leung wrote: > > hi, > > i've just installed openssh-2.3.0p1 on my Debian 2.2 but failed to login > using users' passwords. Password authentication failed all the time and it > prompted "Permission Denied" on the command line. a message, "Failed > password for [user] from .." was logged in auth.log. but i'm sure the > password is correct. i wonder if the configuration for PAM is incorrect. > Below is the content of /etc/pam.d/sshd: ^^ thats supposed to be /etc/pam.d/ssh unless they changed it again... when potato was unstable openssh kept changing back and forth from ssh to sshd, the final is /etc/pam.d/ssh. this would get me since i have pam_deny in my /etc/pam.d/other. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: restricted bash (rbash)
On Wed, Nov 15, 2000 at 03:32:20PM +1300, Nick Clifford wrote: > Pedro Zorzenon Neto wrote: > > > Hi, all > > > > I put /bin/rbash as the default shell (in /etc/passwd) for some users > > that > > I just want them to use a restricted login. > > > > > > Ok, I'm assuming you only want users who have this shell to only be able > to access certian things, run only a limited set of commands? > > If thats the case, then you'd be best to setup a chroot jail. That way > they can't breakout (unless they are root). > > Personally, a chroot jail is the only thing I trust when I need to setup > an isolated or restricted environment. Its difficult to break out of a > chroot jail even when you are root, but it can be done. So ensure they > can't get root. :) chroot is also a very large pain in the backside to setup for interative sessions, i tinkered with the pam_chroot module and ssh and got it barly but messily working. Ben Collins (hope i spelled that right) mentioned he had patched OpenSSH to do a neat trick with chroot logins on debian machines, so developers can login to either a woody or potato chroot. he was going to post the details of what he did but either has not yet or i missed it. Ben? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBykl52EVoc.pgp Description: PGP signature
Re: restricted bash (rbash)
On Wed, Nov 15, 2000 at 03:32:20PM +1300, Nick Clifford wrote: > Pedro Zorzenon Neto wrote: > > > Hi, all > > > > I put /bin/rbash as the default shell (in /etc/passwd) for some users > > that > > I just want them to use a restricted login. > > > > > > Ok, I'm assuming you only want users who have this shell to only be able > to access certian things, run only a limited set of commands? > > If thats the case, then you'd be best to setup a chroot jail. That way > they can't breakout (unless they are root). > > Personally, a chroot jail is the only thing I trust when I need to setup > an isolated or restricted environment. Its difficult to break out of a > chroot jail even when you are root, but it can be done. So ensure they > can't get root. :) chroot is also a very large pain in the backside to setup for interative sessions, i tinkered with the pam_chroot module and ssh and got it barly but messily working. Ben Collins (hope i spelled that right) mentioned he had patched OpenSSH to do a neat trick with chroot logins on debian machines, so developers can login to either a woody or potato chroot. he was going to post the details of what he did but either has not yet or i missed it. Ben? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: buffer overflow in pine <= 4.21
On Mon, Nov 06, 2000 at 09:54:03AM +0100, Thomas Gebhardt wrote: > > it should segfault. good indication of a buffer overflow there. > > While this kind of buffer overflow is nasty, (as far as I can see) > from a security point of view it is rather harmless. not if the program is question is setuid or setgid, in those cases a user may be able to exploit the overflow to obtain elevated privileges. note that the .debs created by the debian pine-src packages install pine setgid mail (uncessarily AFAICT). > If you can get pine to execute arbitrary code just by sending a > malicous mail, that's really dangerous. indeed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpN8QuhZzJ0m.pgp Description: PGP signature
Re: Configuring ssh
On Mon, Nov 06, 2000 at 12:08:17PM +0300, Alan KF LAU wrote: > My major concern is that if you enabled password authentication you'd > leave your system vulnerable to brute force password attacked as in > TELNET. > > Beside, if one could use password authentication, why would one bother > to take all the trouble setting up RSA connection? :) > > I did ask question here, whether I could let one group of user use > password authentication(for casual users with limited access) and the > other group of users use RSA(for admin. users who have higher > privileges). > > Seem like it's not possible, according to expert opinions here, for > current ssh release. > > I might be wrong, please advise if it's possible. I wish to know! :) it is possible, but only as a result of ssh's halfway pam support that this works: add auth required pam_listfile.so item=user sense=deny \ file=/etc/ssh/ssh_rsa_only onerr=succeed to /etc/pam.d/ssh and add RSA only usernames to /etc/ssh/ssh_rsa_only the only reason this works is because ssh ignores (or doesn't run?) all pam auth modules when doing RSA authentication. this is not tested on OpenSSH 2.0, only OpenSSH 1.2* -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGk4jVTMOcV.pgp Description: PGP signature
Re: buffer overflow in pine <= 4.21
On Mon, Nov 06, 2000 at 09:54:03AM +0100, Thomas Gebhardt wrote: > > it should segfault. good indication of a buffer overflow there. > > While this kind of buffer overflow is nasty, (as far as I can see) > from a security point of view it is rather harmless. not if the program is question is setuid or setgid, in those cases a user may be able to exploit the overflow to obtain elevated privileges. note that the .debs created by the debian pine-src packages install pine setgid mail (uncessarily AFAICT). > If you can get pine to execute arbitrary code just by sending a > malicous mail, that's really dangerous. indeed. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Configuring ssh
On Mon, Nov 06, 2000 at 12:08:17PM +0300, Alan KF LAU wrote: > My major concern is that if you enabled password authentication you'd > leave your system vulnerable to brute force password attacked as in > TELNET. > > Beside, if one could use password authentication, why would one bother > to take all the trouble setting up RSA connection? :) > > I did ask question here, whether I could let one group of user use > password authentication(for casual users with limited access) and the > other group of users use RSA(for admin. users who have higher > privileges). > > Seem like it's not possible, according to expert opinions here, for > current ssh release. > > I might be wrong, please advise if it's possible. I wish to know! :) it is possible, but only as a result of ssh's halfway pam support that this works: add auth required pam_listfile.so item=user sense=deny \ file=/etc/ssh/ssh_rsa_only onerr=succeed to /etc/pam.d/ssh and add RSA only usernames to /etc/ssh/ssh_rsa_only the only reason this works is because ssh ignores (or doesn't run?) all pam auth modules when doing RSA authentication. this is not tested on OpenSSH 2.0, only OpenSSH 1.2* -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: buffer overflow in pine <= 4.21
On Fri, Nov 03, 2000 at 06:15:16PM +0100, Robert Varga wrote: > > is the debianized pine4.21 vulnerable to the long From address buffer > overflow vulnerability, which is corrected in 4.30 upstream? pine is riddled with buffer overflows, its considered unfixable without totally throwing away 100% of the code and starting over. why would anyone do that when we have mutt which is a far superior and Free replacement. try this: (iirc) $ export HOME=`perl -e 'print "a" x 1'` $ pine it should segfault. good indication of a buffer overflow there. if you won't apt-get --purge remove pine remove the setgid bit. pine appears to function without it. but that is no protection for users who choose to use it. best advice: switch to mutt. you can configure mutt to act like pine. -- Ethan Benson http://www.alaska.net/~erbenson/ pgppvTkMW7pL8.pgp Description: PGP signature
Re: buffer overflow in pine <= 4.21
On Fri, Nov 03, 2000 at 06:15:16PM +0100, Robert Varga wrote: > > is the debianized pine4.21 vulnerable to the long From address buffer > overflow vulnerability, which is corrected in 4.30 upstream? pine is riddled with buffer overflows, its considered unfixable without totally throwing away 100% of the code and starting over. why would anyone do that when we have mutt which is a far superior and Free replacement. try this: (iirc) $ export HOME=`perl -e 'print "a" x 1'` $ pine it should segfault. good indication of a buffer overflow there. if you won't apt-get --purge remove pine remove the setgid bit. pine appears to function without it. but that is no protection for users who choose to use it. best advice: switch to mutt. you can configure mutt to act like pine. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Fri, Nov 03, 2000 at 10:22:32AM +0100, Michael Meskes wrote: > On Thu, Nov 02, 2000 at 10:09:10AM -0600, An Thi-Nguyen Le wrote: > > set up myself that has a default potato debian install, with postfix > > (default as well). > > Well I do run woody, but: > > [EMAIL PROTECTED]:~$ telnet localhost 25 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 feivel ESMTP Postfix > HELO urh1000.uiuc.edu > 250 feivel > MAIL FROM:<[EMAIL PROTECTED]> > 250 Ok > RCPT TO:<[EMAIL PROTECTED]> > 250 Ok > > I take it this is relaying isn't it? The only additions I have to > /etc/postfix/main.cf are: no, machines in your network are allowed to relay, if i were to connect to your port 25 (which i won't) and try the same thing it would refuse to accept it. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZeuwPZ0G9Z.pgp Description: PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Fri, Nov 03, 2000 at 10:22:32AM +0100, Michael Meskes wrote: > On Thu, Nov 02, 2000 at 10:09:10AM -0600, An Thi-Nguyen Le wrote: > > set up myself that has a default potato debian install, with postfix > > (default as well). > > Well I do run woody, but: > > mme@feivel:~$ telnet localhost 25 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 feivel ESMTP Postfix > HELO urh1000.uiuc.edu > 250 feivel > MAIL FROM:<[EMAIL PROTECTED]> > 250 Ok > RCPT TO:<[EMAIL PROTECTED]> > 250 Ok > > I take it this is relaying isn't it? The only additions I have to > /etc/postfix/main.cf are: no, machines in your network are allowed to relay, if i were to connect to your port 25 (which i won't) and try the same thing it would refuse to accept it. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 01:17:21PM +0100, Peter Palfrader wrote: > Hi! > > On Thu, 02 Nov 2000, Borut Mrak wrote: > > > On Thu, Nov 02, 2000 at 02:24:36AM -0900, Ethan Benson wrote: > > > so my question now is postfix a open relay by default or not? > > > > No. > > It is. For a (not so) small set of hosts. Assuming your box is 62.1.2.3 you > will be an open relay for the entire _class_A_ net 62. > > If you do not set mynetworks postfix guesses it from the interfaces and allows > all hosts on the classful subnets of those interfaces to relay through you. ah! i see didn't think of that one... so you need to specify mynetworks with the correct subnet. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpXEhVIGWmDI.pgp Description: PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 12:05:00PM +0100, Borut Mrak wrote: > > Hmm...wise decision ;-] indeed... > mail-abuse.org just test relaying...and postfix fails the test, but doesn't it fails? since when? or rather what are you defining as failure? in my tests it refused to relay each and every attempt from them. > relay anyway... In our case, the mail is not going to be relayed but > delivered localy. It's the responsibility of the admin to decide what > envelope From (and other stuff) he is going to accept. The default should > stay open. OK, yes thats what i thought those options did, restrict what mail postfix will accept to itself, not anything to do with actual relaying to elsewhere. > > can someone else running a production postfix server comment on this? > > Well...let's just say that if your DNS is flaky, this wouldn't be a good > option to add. The message will be rejected with a 4xx code, meaning the > sending host will try for a few days and then stop. > It catches some spam, though. yes, those option then only protect local users from receiving crap, but has nothing to do with relaying spam. so my question now is postfix a open relay by default or not? > IMO, if the volume of spam is of concern to an admin, he should read the > docs and fix it himself. yes. i am forwarding this back to the list. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp2qfkh5IjQe.pgp Description: PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 11:49:35AM +0100, Ingemar Fällman wrote: > Try this :) > > telnet some.other.host.running.postfix 25 > HELO my.hostname > MAIL FROM:<[EMAIL PROTECTED]> > RCPT TO:<[EMAIL PROTECTED]> > DATA > Testing testing > . > QUIT well i don't know anyone running postfix who i can ask to test this with... im certainly not going to go try it without asking ! bad karma ;-) but i really recall that kind of test being included in the mail-abuse.org suite. unfortuantly im not running a mailserver anymore. so i cannot really do much real testing.. my fake DNSless lan would not be very accurate ;-) can someone else running a production postfix server comment on this? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpxL604fg4sj.pgp Description: PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 10:42:38AM +0100, Ingemar Fällman wrote: > Hi > > When i was looking trough my logs tody i found that my host had been > used > as a relay host... I changed from sendmail to postfix because everyone > told > me that postfix was more secure. > > When looking at the default configurationfiles installed by debian there > was > nothing that prevents unauthorized users to send mail to anyone. did you run a test to see if this was really the case? such as telnet mail-abuse.org i have run such a test on a default potato postfix setup and it passed all those tests, is there some other relay method that it does not catch? > By adding this line to main.cf you can make sure that only your host can > send mail to users outside your system: > > smtpd_sender_restrictions = check_relay_domains, from the smtpd man page: smtpd_sender_restrictions Restrict what sender addresses are allowed in MAIL FROM commands. it is true that postfix does not tend to care what you put in a FROM but that does not mean it allows relay (just watch the mail-abuse.org tests) what postfix does is check to see whether the TO address is local, and if not it checks whether the connecting user is within the allowed relay domain (which is by default only the domain of the mailhost) if not it refuses the message. > reject_unknown_sender_domain didn't find this one.. (didnt search through all the man pages) > Is this someting that should be added by default?? I think so no MTA should ever be a open relay much less by default, but from my testing postfix is not. are you sure your using the debian current packages and not some old ones? there was an old broken version of postfix way back when that was a open relay, it was a bug long ago fixed. (its in the FAQ) but then i could be missing something, im tired ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHP4efrsvcD.pgp Description: PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 01:17:21PM +0100, Peter Palfrader wrote: > Hi! > > On Thu, 02 Nov 2000, Borut Mrak wrote: > > > On Thu, Nov 02, 2000 at 02:24:36AM -0900, Ethan Benson wrote: > > > so my question now is postfix a open relay by default or not? > > > > No. > > It is. For a (not so) small set of hosts. Assuming your box is 62.1.2.3 you > will be an open relay for the entire _class_A_ net 62. > > If you do not set mynetworks postfix guesses it from the interfaces and allows > all hosts on the classful subnets of those interfaces to relay through you. ah! i see didn't think of that one... so you need to specify mynetworks with the correct subnet. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 12:05:00PM +0100, Borut Mrak wrote: > > Hmm...wise decision ;-] indeed... > mail-abuse.org just test relaying...and postfix fails the test, but doesn't it fails? since when? or rather what are you defining as failure? in my tests it refused to relay each and every attempt from them. > relay anyway... In our case, the mail is not going to be relayed but > delivered localy. It's the responsibility of the admin to decide what > envelope From (and other stuff) he is going to accept. The default should > stay open. OK, yes thats what i thought those options did, restrict what mail postfix will accept to itself, not anything to do with actual relaying to elsewhere. > > can someone else running a production postfix server comment on this? > > Well...let's just say that if your DNS is flaky, this wouldn't be a good > option to add. The message will be rejected with a 4xx code, meaning the > sending host will try for a few days and then stop. > It catches some spam, though. yes, those option then only protect local users from receiving crap, but has nothing to do with relaying spam. so my question now is postfix a open relay by default or not? > IMO, if the volume of spam is of concern to an admin, he should read the > docs and fix it himself. yes. i am forwarding this back to the list. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 11:49:35AM +0100, Ingemar Fällman wrote: > Try this :) > > telnet some.other.host.running.postfix 25 > HELO my.hostname > MAIL FROM:<[EMAIL PROTECTED]> > RCPT TO:<[EMAIL PROTECTED]> > DATA > Testing testing > . > QUIT well i don't know anyone running postfix who i can ask to test this with... im certainly not going to go try it without asking ! bad karma ;-) but i really recall that kind of test being included in the mail-abuse.org suite. unfortuantly im not running a mailserver anymore. so i cannot really do much real testing.. my fake DNSless lan would not be very accurate ;-) can someone else running a production postfix server comment on this? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Postfix is spammer-friendly by default on potato and woody
On Thu, Nov 02, 2000 at 10:42:38AM +0100, Ingemar Fällman wrote: > Hi > > When i was looking trough my logs tody i found that my host had been > used > as a relay host... I changed from sendmail to postfix because everyone > told > me that postfix was more secure. > > When looking at the default configurationfiles installed by debian there > was > nothing that prevents unauthorized users to send mail to anyone. did you run a test to see if this was really the case? such as telnet mail-abuse.org i have run such a test on a default potato postfix setup and it passed all those tests, is there some other relay method that it does not catch? > By adding this line to main.cf you can make sure that only your host can > send mail to users outside your system: > > smtpd_sender_restrictions = check_relay_domains, from the smtpd man page: smtpd_sender_restrictions Restrict what sender addresses are allowed in MAIL FROM commands. it is true that postfix does not tend to care what you put in a FROM but that does not mean it allows relay (just watch the mail-abuse.org tests) what postfix does is check to see whether the TO address is local, and if not it checks whether the connecting user is within the allowed relay domain (which is by default only the domain of the mailhost) if not it refuses the message. > reject_unknown_sender_domain didn't find this one.. (didnt search through all the man pages) > Is this someting that should be added by default?? I think so no MTA should ever be a open relay much less by default, but from my testing postfix is not. are you sure your using the debian current packages and not some old ones? there was an old broken version of postfix way back when that was a open relay, it was a bug long ago fixed. (its in the FAQ) but then i could be missing something, im tired ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: what is on port 13223
On Thu, Oct 12, 2000 at 02:34:47PM +0300, Alan KF LAU wrote: > Are you using dialup? It's probably a stray connection attempt from previous > user's chatmates. > > Check http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html > and look for 13223. thanks for the info, yes i am on a dialup, but the connection has been up for over 8 hours and im still getting these connections. just for good measure i added a firewall rule for it, but nothing was listening there anyway. > Don't worry about it.. its annoying not worrisome ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZF67bk3xzS.pgp Description: PGP signature
what is on port 13223
Does anyone know what port 13223 is? today i have been getting a massive number of connection attempts to that port from several different addresses. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJxH5D67j0N.pgp Description: PGP signature
Re: what is on port 13223
On Thu, Oct 12, 2000 at 02:34:47PM +0300, Alan KF LAU wrote: > Are you using dialup? It's probably a stray connection attempt from previous user's >chatmates. > > Check http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html > and look for 13223. thanks for the info, yes i am on a dialup, but the connection has been up for over 8 hours and im still getting these connections. just for good measure i added a firewall rule for it, but nothing was listening there anyway. > Don't worry about it.. its annoying not worrisome ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
what is on port 13223
Does anyone know what port 13223 is? today i have been getting a massive number of connection attempts to that port from several different addresses. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: su vulnerability
On Mon, Oct 09, 2000 at 03:04:35PM +0200, Javier Fernandez-Sanguino Peña wrote: > > One thing I wonder is why does not Debian issue advisories to popular > mailing > lists (linux-security on securityportal and bugtrack on securityfocus comes to they do post announcments to BugTraq, at least every advisory i get from debian-security-announce is cross posted to BugTraq too. > mind). Also, I do not see this posted at security.debian.org > I am currently maintaining my status as Debian maintainer but starting > to move > my focus towards security (I finished my life as student and working now on a > security related company). > So, I'm willing to help the security team in posting these > announcements (both > on web and on security lists). It seems that some hands might be needed :) > I have another proyect in mind, but will send it later on... i am a bit curious about the recent traceroute bug, (traceroute -g 1 -g 1 segfaults) pretty much every other major dist has released an advisory and update for this, but debian appears not to have (unless i missed it). a fixed traceroute package does exist in proposed-updates however. (its been there for awhile now) same thing with tmpreaper (aka tmpwatch) (even though thats only a DoS solved easily by disk file quotas) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6NC6BrNWu8.pgp Description: PGP signature
Re: su vulnerability
On Mon, Oct 09, 2000 at 03:04:35PM +0200, Javier Fernandez-Sanguino Peña wrote: > > One thing I wonder is why does not Debian issue advisories to popular mailing > lists (linux-security on securityportal and bugtrack on securityfocus comes to they do post announcments to BugTraq, at least every advisory i get from debian-security-announce is cross posted to BugTraq too. > mind). Also, I do not see this posted at security.debian.org > I am currently maintaining my status as Debian maintainer but starting to move > my focus towards security (I finished my life as student and working now on a > security related company). > So, I'm willing to help the security team in posting these announcements (both > on web and on security lists). It seems that some hands might be needed :) > I have another proyect in mind, but will send it later on... i am a bit curious about the recent traceroute bug, (traceroute -g 1 -g 1 segfaults) pretty much every other major dist has released an advisory and update for this, but debian appears not to have (unless i missed it). a fixed traceroute package does exist in proposed-updates however. (its been there for awhile now) same thing with tmpreaper (aka tmpwatch) (even though thats only a DoS solved easily by disk file quotas) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
updated syslogd for powerpc, when?
recently there was a format string bug found in klogd, this was fixed in sysklogd 1.3-33.1, however this package was not released for powerpc, AFAICT this still has not happened. when the advisory came out i downloaded the source to sysklogd from security.debian.org (the updated package source) and compiled a .deb which seems to work perfectly. so why is there still no updated package for powerpc? (i checked in security.debian.org ftp and did not see a package there.) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpLxedAOBo1O.pgp Description: PGP signature
updated syslogd for powerpc, when?
recently there was a format string bug found in klogd, this was fixed in sysklogd 1.3-33.1, however this package was not released for powerpc, AFAICT this still has not happened. when the advisory came out i downloaded the source to sysklogd from security.debian.org (the updated package source) and compiled a .deb which seems to work perfectly. so why is there still no updated package for powerpc? (i checked in security.debian.org ftp and did not see a package there.) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 02:56:02AM +, Jim Breton wrote: > On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote: > > > > Still, why does /var/lib/texmf/* need to be publically writeable? > > > > > > design flaws in tetex. see the BTS for a long discussion about it. > > Which packages adds these world-writable dirs/files? My system is not > set up this way: > > $ l /var/lib/texmf/ > total 114 > -rw-r--r--1 root root67051 Apr 17 11:07 ls-R > -rw-r--r--1 root root43552 Mar 5 2000 lsR12124.tmp > drwxr-xr-x2 root root 3072 Apr 17 11:07 web2c s/lib/spool/ -- Ethan Benson http://www.alaska.net/~erbenson/ pgpX7DziT3giG.pgp Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote: > > No. It's just not globally writeable. ah > > > Still, why does /var/lib/texmf/* need to be publically writeable? > > > > design flaws in tetex. see the BTS for a long discussion about it. i actually misspoke here, its really /var/spool/texmf/* that is world writable. > > BTS? Bug Tracking System http://www.debian.org/Bugs i don't remember which tetex package has the long conversion about the issue though... > > its not trivial to fix unfortunatly. > > doh. what do those files do? (if you know offhand) i don't remember exactly tex is totally broken unless they are writable by all though. > > most people do since its priority standard. > > aye. I'd say it needs fixing also then. :) agreed but it will probably need fixing upstream, the changes are really too much for debian to do themselves. > I'll be grabbing this when my HD stops getting roasted. it appears to work ok and its supposed to be safe from races.. (though i have not read the code...) > > still i don't think its good to overload /tmp with this kind of > > garbage more then necessary or that list could get rediculous. > > Yes it could but then I think that's better then the alternative... > and if you REALLY wanted to, you could have a .debian or whatnot > dir in there to store all such things (or most of them/some of them) this is becoming a question for debian-devel or perhaps debian-policy. > > FHS may answer some of these questions too. > > FHS? :) Filesystem Hierarchy Standard http://www.pathname.com/fhs/ -- Ethan Benson http://www.alaska.net/~erbenson/ pgpjNwrmkEkhv.pgp Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> For my system:
>
> [13:09:22] [EMAIL PROTECTED]:/root>> find /var -perm +o+w -mount
> [13:09:26] [EMAIL PROTECTED]:/root>>
>
> I've not had problems. :)
you have removed /var/lock? and i presume made /var/tmp its own
partition.
> Still, why does /var/lib/texmf/* need to be publically writeable?
design flaws in tetex. see the BTS for a long discussion about it.
its not trivial to fix unfortunatly.
> That's a package I don't have installed.
most people do since its priority standard.
> > if your worried about users messing with /var put quotas on /var.
>
> If that's the only solution then yes, but why do we need global
> write access to /var in the first place?
/var/lock i am not sure about, i don't usually see anything in there,
though right now i see a
-rw-r--r--1 root root 11 Sep 8 18:10 LCK..ttyS0
which belongs to pppd, but it runs as root.
/var/lock is cleaned on boot.
> > more headaches for /tmp cleaners and it does not solve any of the
> > above problems. to solve the above problems enforce quotas on /var
>
> Well it does... Logging will go on etc. As for /tmp cleaners, somehting
> like tmpwatch is a good start, but it'd be nice if it had an exclusion
> list to the global timeout. It'd make it much more useful. :)
like this (from /etc/cron.daily/tmpreaper):
# ! Important ! Please read the manual regarding the --protect option.
#The pattern *MUST* be surrounded by single quotes.
nice -n10 tmpreaper --mtime-dir --symlinks 7d \
--protect '/tmp/.X*-{lock,unix,unix/*}' \
--protect '/tmp/.ICE-{unix,unix/*}' \
--protect '/tmp/.iroha_{unix,unix/*}' \
--protect '/tmp/.ki2-{unix,unix/*}' \
--protect '/tmp/.font-unix' \
--protect '/tmp/lost+found' \
--protect '/tmp/quota.user' \
--protect '/tmp/quota.group' \
/tmp
still i don't think its good to overload /tmp with this kind of
garbage more then necessary or that list could get rediculous.
FHS may answer some of these questions too.
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpCINSTwcPoE.pgp
Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:10:23PM +1100, Herbert Xu wrote: > > How will they do that if the only thing owned by screen are the directories? > You can always do fstat after an open. oh i misunderstood you, what would happen if they removed the socket? i would guess nothing if sockets work like any other file if they are `open' i still maintain that users owning a directory in /var/run/screen is not really a big deal since there are loads of world writable directories in /var. maybe if tex is fixed i might be convinced. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpPdV4RFBK14.pgp Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
hmm quota seems to stop that just fine here:
[EMAIL PROTECTED] eb]$ cd /var/lock/
[EMAIL PROTECTED] lock]$ df /var
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda8 1032088298940680720 31% /var
[EMAIL PROTECTED] lock]$ cat /dev/zero > bloat
/var: warning, user disk quota exceeded
/var: write failed, user disk limit
reached.
cat: write error: Disk quota exceeded
[EMAIL PROTECTED] lock]$ df /var
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda8 1032088314260665400 32% /var
[EMAIL PROTECTED] lock]$
now what quota (nor moving /var/run/screen) will NOT fix is stuffing
/var via /usr/bin/logger (that is just a bit more work then the above)
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpY62bhcbBUt.pgp
Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 10:30:26AM +1100, Herbert Xu wrote: > CaT <[EMAIL PROTECTED]> wrote: > > > > What screen does there is to create subdirs which are then used > > to hold a users pipes. Now these subdirs are owned by the user > > that runs screen. The hassle with this is that it gives the user > > What about making screen setuid screen and make screen the owner of those > directories? i think this is a bad idea, if another hole is found in screen then users can spy on other users sessions. as it is now if a hole is in screen users can mess with the utmp file, thats it. which is not that big a deal. (i have had lots of buggy programs which screw that up anyway) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpP0I5dtBZDS.pgp Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote: > After installing this utility (which has to be amongst my very > favourite) I noticed something interesting int he way it behaves. > Basically, screen does what I first thought of when compiling it > for myself, which is to put its pipes in /var/run/screen. > > What screen does there is to create subdirs which are then used > to hold a users pipes. Now these subdirs are owned by the user > that runs screen. The hassle with this is that it gives the user > a. a possible way around quotas set on /home b. a method of fully > filling up /var, thereby potentially causing log entries to be > lost which, in turn, gives the user anice, untracable way of then > doing naughty things without those naughty things getting logged. > Said user can then rm the large file they created and noone would > be any the wiser. users have write permission to /var unless you really make alot of changes, on my system i have: /var/lock /var/tmp ## for me this is a sep partition /var/lib/texmf/* /var/mail/user if your worried about users messing with /var put quotas on /var. > As such I reckon it's best if the screen directory is left in > /tmp where the authors initially put it. It's inconvenient but > doesn't cause the problems above. more headaches for /tmp cleaners and it does not solve any of the above problems. to solve the above problems enforce quotas on /var (which can be much smaller then /home quotas, say 5 or 10 MB) that is what i do. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpLBHLlglre0.pgp Description: PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 02:56:02AM +, Jim Breton wrote: > On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote: > > > > Still, why does /var/lib/texmf/* need to be publically writeable? > > > > > > design flaws in tetex. see the BTS for a long discussion about it. > > Which packages adds these world-writable dirs/files? My system is not > set up this way: > > $ l /var/lib/texmf/ > total 114 > -rw-r--r--1 root root67051 Apr 17 11:07 ls-R > -rw-r--r--1 root root43552 Mar 5 2000 lsR12124.tmp > drwxr-xr-x2 root root 3072 Apr 17 11:07 web2c s/lib/spool/ -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote: > > No. It's just not globally writeable. ah > > > Still, why does /var/lib/texmf/* need to be publically writeable? > > > > design flaws in tetex. see the BTS for a long discussion about it. i actually misspoke here, its really /var/spool/texmf/* that is world writable. > > BTS? Bug Tracking System http://www.debian.org/Bugs i don't remember which tetex package has the long conversion about the issue though... > > its not trivial to fix unfortunatly. > > doh. what do those files do? (if you know offhand) i don't remember exactly tex is totally broken unless they are writable by all though. > > most people do since its priority standard. > > aye. I'd say it needs fixing also then. :) agreed but it will probably need fixing upstream, the changes are really too much for debian to do themselves. > I'll be grabbing this when my HD stops getting roasted. it appears to work ok and its supposed to be safe from races.. (though i have not read the code...) > > still i don't think its good to overload /tmp with this kind of > > garbage more then necessary or that list could get rediculous. > > Yes it could but then I think that's better then the alternative... > and if you REALLY wanted to, you could have a .debian or whatnot > dir in there to store all such things (or most of them/some of them) this is becoming a question for debian-devel or perhaps debian-policy. > > FHS may answer some of these questions too. > > FHS? :) Filesystem Hierarchy Standard http://www.pathname.com/fhs/ -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> For my system:
>
> [13:09:22] root@nessie:/root>> find /var -perm +o+w -mount
> [13:09:26] root@nessie:/root>>
>
> I've not had problems. :)
you have removed /var/lock? and i presume made /var/tmp its own
partition.
> Still, why does /var/lib/texmf/* need to be publically writeable?
design flaws in tetex. see the BTS for a long discussion about it.
its not trivial to fix unfortunatly.
> That's a package I don't have installed.
most people do since its priority standard.
> > if your worried about users messing with /var put quotas on /var.
>
> If that's the only solution then yes, but why do we need global
> write access to /var in the first place?
/var/lock i am not sure about, i don't usually see anything in there,
though right now i see a
-rw-r--r--1 root root 11 Sep 8 18:10 LCK..ttyS0
which belongs to pppd, but it runs as root.
/var/lock is cleaned on boot.
> > more headaches for /tmp cleaners and it does not solve any of the
> > above problems. to solve the above problems enforce quotas on /var
>
> Well it does... Logging will go on etc. As for /tmp cleaners, somehting
> like tmpwatch is a good start, but it'd be nice if it had an exclusion
> list to the global timeout. It'd make it much more useful. :)
like this (from /etc/cron.daily/tmpreaper):
# ! Important ! Please read the manual regarding the --protect option.
#The pattern *MUST* be surrounded by single quotes.
nice -n10 tmpreaper --mtime-dir --symlinks 7d \
--protect '/tmp/.X*-{lock,unix,unix/*}' \
--protect '/tmp/.ICE-{unix,unix/*}' \
--protect '/tmp/.iroha_{unix,unix/*}' \
--protect '/tmp/.ki2-{unix,unix/*}' \
--protect '/tmp/.font-unix' \
--protect '/tmp/lost+found' \
--protect '/tmp/quota.user' \
--protect '/tmp/quota.group' \
/tmp
still i don't think its good to overload /tmp with this kind of
garbage more then necessary or that list could get rediculous.
FHS may answer some of these questions too.
--
Ethan Benson
http://www.alaska.net/~erbenson/
PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 01:10:23PM +1100, Herbert Xu wrote: > > How will they do that if the only thing owned by screen are the directories? > You can always do fstat after an open. oh i misunderstood you, what would happen if they removed the socket? i would guess nothing if sockets work like any other file if they are `open' i still maintain that users owning a directory in /var/run/screen is not really a big deal since there are loads of world writable directories in /var. maybe if tex is fixed i might be convinced. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: possible security flaw in screen 3.9.5-9
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
hmm quota seems to stop that just fine here:
[eb@socrates eb]$ cd /var/lock/
[eb@socrates lock]$ df /var
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda8 1032088298940680720 31% /var
[eb@socrates lock]$ cat /dev/zero > bloat
/var: warning, user disk quota exceeded
/var: write failed, user disk limit reached.
cat: write error: Disk quota exceeded
[eb@socrates lock]$ df /var
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda8 1032088314260665400 32% /var
[eb@socrates lock]$
now what quota (nor moving /var/run/screen) will NOT fix is stuffing
/var via /usr/bin/logger (that is just a bit more work then the above)
--
Ethan Benson
http://www.alaska.net/~erbenson/
PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 10:30:26AM +1100, Herbert Xu wrote: > CaT <[EMAIL PROTECTED]> wrote: > > > > What screen does there is to create subdirs which are then used > > to hold a users pipes. Now these subdirs are owned by the user > > that runs screen. The hassle with this is that it gives the user > > What about making screen setuid screen and make screen the owner of those > directories? i think this is a bad idea, if another hole is found in screen then users can spy on other users sessions. as it is now if a hole is in screen users can mess with the utmp file, thats it. which is not that big a deal. (i have had lots of buggy programs which screw that up anyway) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: possible security flaw in screen 3.9.5-9
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote: > After installing this utility (which has to be amongst my very > favourite) I noticed something interesting int he way it behaves. > Basically, screen does what I first thought of when compiling it > for myself, which is to put its pipes in /var/run/screen. > > What screen does there is to create subdirs which are then used > to hold a users pipes. Now these subdirs are owned by the user > that runs screen. The hassle with this is that it gives the user > a. a possible way around quotas set on /home b. a method of fully > filling up /var, thereby potentially causing log entries to be > lost which, in turn, gives the user anice, untracable way of then > doing naughty things without those naughty things getting logged. > Said user can then rm the large file they created and noone would > be any the wiser. users have write permission to /var unless you really make alot of changes, on my system i have: /var/lock /var/tmp ## for me this is a sep partition /var/lib/texmf/* /var/mail/user if your worried about users messing with /var put quotas on /var. > As such I reckon it's best if the screen directory is left in > /tmp where the authors initially put it. It's inconvenient but > doesn't cause the problems above. more headaches for /tmp cleaners and it does not solve any of the above problems. to solve the above problems enforce quotas on /var (which can be much smaller then /home quotas, say 5 or 10 MB) that is what i do. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
ssh-agent bug?
i recently noticed something odd about the way forwarded ssh-agent sessions work: when i use ssh-agent and allow it to be forwarded to another host (trusted of course) i noticed that the remote agent does not appear to drop privileges, notice how the socket and socket directory are created in /tmp: [EMAIL PROTECTED] eb]$ ll -d /tmp/ssh-ONn15369/ drwx--2 eb root 1024 Jul 1 12:53 /tmp/ssh-ONn15369/ [EMAIL PROTECTED] eb]$ ll /tmp/ssh-ONn15369/ total 0 srwxr-xr-x1 eb root0 Jul 1 12:53 agent.15369 two problems i see here, 1) the agent is not dropping gid=root privileges when creating the socket, and 2) the agent is not setting a proper create mode when the actual socket is created, the socket should have 0600 permissions IMO, even if it is protected by a `gate' directory. and then i noticed this: [EMAIL PROTECTED] eb]$ ps aux | grep 15369 root 15369 0.1 1.8 3244 1724 ?S12:53 0:00 /usr/sbin/sshd eb 15398 0.0 0.5 1260 480 pts/0S12:59 0:00 grep 15369 [EMAIL PROTECTED] eb]$ ps aufx | grep sshd root 14037 0.0 0.9 2240 944 ?SJun28 0:06 /usr/sbin/sshd root 15369 0.1 1.8 3244 1724 ?S12:53 0:00 \_ /usr/sbin/sshd eb 15400 0.0 0.5 1260 480 pts/0S12:59 0:00 \_ grep sshd [EMAIL PROTECTED] eb]$ why isn't a ssh-agent process forked to handle the socket? instead we have a fully root owned process listening on a socket, is that safe? -- Ethan Benson http://www.alaska.net/~erbenson/ pgp43KHwR50fq.pgp Description: PGP signature
Re: recent gpm DoS issue
On Mon, Jul 31, 2000 at 03:07:38AM +, Jim Breton wrote: > On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote: > > we we could just fix the DoS in gpm, no? > > Presumably so, though I'm not sure how the internals of gpm work... it > is conceivable that any data written to that socket in the right format > (or whatever) would be read as valid by the gpm process. Over my head! > ;) But the principle of "minimum permissions necessary" would still be > worth employing, assuming it could be done without a significant > negative impact on the operation of the software there is another point, how necessary is it for gpm to run as root? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpe1k0AUA5fA.pgp Description: PGP signature
ssh-agent bug?
i recently noticed something odd about the way forwarded ssh-agent sessions work: when i use ssh-agent and allow it to be forwarded to another host (trusted of course) i noticed that the remote agent does not appear to drop privileges, notice how the socket and socket directory are created in /tmp: [eb@dogbert eb]$ ll -d /tmp/ssh-ONn15369/ drwx--2 eb root 1024 Jul 1 12:53 /tmp/ssh-ONn15369/ [eb@dogbert eb]$ ll /tmp/ssh-ONn15369/ total 0 srwxr-xr-x1 eb root0 Jul 1 12:53 agent.15369 two problems i see here, 1) the agent is not dropping gid=root privileges when creating the socket, and 2) the agent is not setting a proper create mode when the actual socket is created, the socket should have 0600 permissions IMO, even if it is protected by a `gate' directory. and then i noticed this: [eb@dogbert eb]$ ps aux | grep 15369 root 15369 0.1 1.8 3244 1724 ?S12:53 0:00 /usr/sbin/sshd eb 15398 0.0 0.5 1260 480 pts/0S12:59 0:00 grep 15369 [eb@dogbert eb]$ ps aufx | grep sshd root 14037 0.0 0.9 2240 944 ?SJun28 0:06 /usr/sbin/sshd root 15369 0.1 1.8 3244 1724 ?S12:53 0:00 \_ /usr/sbin/sshd eb 15400 0.0 0.5 1260 480 pts/0S12:59 0:00 \_ grep sshd [eb@dogbert eb]$ why isn't a ssh-agent process forked to handle the socket? instead we have a fully root owned process listening on a socket, is that safe? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: recent gpm DoS issue
On Mon, Jul 31, 2000 at 03:07:38AM +, Jim Breton wrote: > On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote: > > we we could just fix the DoS in gpm, no? > > Presumably so, though I'm not sure how the internals of gpm work... it > is conceivable that any data written to that socket in the right format > (or whatever) would be read as valid by the gpm process. Over my head! > ;) But the principle of "minimum permissions necessary" would still be > worth employing, assuming it could be done without a significant > negative impact on the operation of the software there is another point, how necessary is it for gpm to run as root? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote:
> On Sat, Jul 29, 2000 at 03:37:30AM +, Jim Breton wrote:
> >
> > Yup. Until we have a package which sets restricted permissions on its
> > own, when it creates the socket. :-{
>
> we we could just fix the DoS in gpm, no?
i just tried changing the permissions on /dev/gpmctl to mode 0600
root.root and gpm still works just fine, at least for what i use it
for (simple copy and paste of text, nothing more).
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpsM2W2TOhNb.pgp
Description: PGP signature
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 03:37:30AM +, Jim Breton wrote:
>
> Yup. Until we have a package which sets restricted permissions on its
> own, when it creates the socket. :-{
we we could just fix the DoS in gpm, no?
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpBUWm6B9m9K.pgp
Description: PGP signature
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote:
> On Sat, Jul 29, 2000 at 03:37:30AM +, Jim Breton wrote:
> >
> > Yup. Until we have a package which sets restricted permissions on its
> > own, when it creates the socket. :-{
>
> we we could just fix the DoS in gpm, no?
i just tried changing the permissions on /dev/gpmctl to mode 0600
root.root and gpm still works just fine, at least for what i use it
for (simple copy and paste of text, nothing more).
--
Ethan Benson
http://www.alaska.net/~erbenson/
PGP signature
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 03:37:30AM +, Jim Breton wrote:
>
> Yup. Until we have a package which sets restricted permissions on its
> own, when it creates the socket. :-{
we we could just fix the DoS in gpm, no?
--
Ethan Benson
http://www.alaska.net/~erbenson/
PGP signature
Re: recent gpm DoS issue
On Fri, Jul 28, 2000 at 08:11:12AM +, Jim Breton wrote: > On Thu, Jul 27, 2000 at 11:56:03PM -0800, Ethan Benson wrote: > > pam_group is only relativly secure if your system is installed and > > configured a certain way: > > Yup, some of that is mentioned in the documentation... nevertheless, it > would be a big improvement over making the socket world-writable. perhaps, or perhaps only trusted users should be granted gid=mouse. > Red Hat are using a pam_console module for this, here is an excerpt from > their advisory: > > "For 6.x, the /dev/gpmctl ownership issue was addressed via the > pam_console helper mechanism. This pam module makes devices > which need to be accessible via console users owned by them and > no one else." pam_console is evil. its a bigger security hole then gpmctl is. besides that pam_console is not secure anyway since one can hold a file descriptor open on anything except a tty thus retaining access even when permissions/owners are changed. (that may not work on a socket, i don't really know) > > > what is gpmctl actually used for anyway? > > I don't know exactly! ;) But here's what the gpm man page says: > >/dev/gpmctl A control socket for clients gee thats descriptive... > And the file only exists while gpm is running (it's removed when you > stop gpm) so I am guessing it is the socket through which clients read > mouse data. that means you have to play games with the initscript to change its permissions.. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp3eVOZ7RJ1R.pgp Description: PGP signature
Re: recent gpm DoS issue
On Fri, Jul 28, 2000 at 08:11:12AM +, Jim Breton wrote: > On Thu, Jul 27, 2000 at 11:56:03PM -0800, Ethan Benson wrote: > > pam_group is only relativly secure if your system is installed and > > configured a certain way: > > Yup, some of that is mentioned in the documentation... nevertheless, it > would be a big improvement over making the socket world-writable. perhaps, or perhaps only trusted users should be granted gid=mouse. > Red Hat are using a pam_console module for this, here is an excerpt from > their advisory: > > "For 6.x, the /dev/gpmctl ownership issue was addressed via the > pam_console helper mechanism. This pam module makes devices > which need to be accessible via console users owned by them and > no one else." pam_console is evil. its a bigger security hole then gpmctl is. besides that pam_console is not secure anyway since one can hold a file descriptor open on anything except a tty thus retaining access even when permissions/owners are changed. (that may not work on a socket, i don't really know) > > > what is gpmctl actually used for anyway? > > I don't know exactly! ;) But here's what the gpm man page says: > >/dev/gpmctl A control socket for clients gee thats descriptive... > And the file only exists while gpm is running (it's removed when you > stop gpm) so I am guessing it is the socket through which clients read > mouse data. that means you have to play games with the initscript to change its permissions.. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: recent gpm DoS issue
On Fri, Jul 28, 2000 at 06:53:51AM +, Jim Breton wrote: > Do we have any plans in the works for a fix similar to what Red Hat are > doing? > > Running potato here, and the permissions on /dev/gpmctl are indeed 777. > > I am thinking about changing the group ownership on mine to "mouse" > (creating that group) and using the /etc/security/group.conf mechanism > to put console users into that group. > > Sound like a good plan, or is there something better? pam_group is only relativly secure if your system is installed and configured a certain way: /tmp and /var and /home being their own partitions and mounted nosuid. even still one can leave a process running with the group privileges quite easily... man screen. what is gpmctl actually used for anyway? -- Ethan Benson http://www.alaska.net/~erbenson/ pgprkFfJOy6oE.pgp Description: PGP signature
Re: recent gpm DoS issue
On Fri, Jul 28, 2000 at 06:53:51AM +, Jim Breton wrote: > Do we have any plans in the works for a fix similar to what Red Hat are > doing? > > Running potato here, and the permissions on /dev/gpmctl are indeed 777. > > I am thinking about changing the group ownership on mine to "mouse" > (creating that group) and using the /etc/security/group.conf mechanism > to put console users into that group. > > Sound like a good plan, or is there something better? pam_group is only relativly secure if your system is installed and configured a certain way: /tmp and /var and /home being their own partitions and mounted nosuid. even still one can leave a process running with the group privileges quite easily... man screen. what is gpmctl actually used for anyway? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Sendmail Workaround for Linux Capabilities Bug (fwd)
On Thu, Jun 08, 2000 at 02:03:21PM +0200, Wichert Akkerman wrote: > Previously Christian Hammers wrote: > > Is it right that there must exist a vulnerability in the server, too that > > allowes the attacker to execute code to exploit the capabilities bug? > > In other words, how severe is the urge to update the kernels on our > > production systems? > > It indeed requires local access to the machine. there is however a sunrpc fix in 2.2.16 that Alan Cox feels is remotely exploitable. if your not running sunrpc you should be ok there though.. still it is not a good idea to leave local holes open since there are other ways to get local access, (say a bad CGI in apache, could get you a www-data shell) or of course bind, wu-ftpd etc. -- Ethan Benson http://www.alaska.net/~erbenson/ pgptbO3ET77i6.pgp Description: PGP signature
Re: suid shell scripts
On Tue, Jun 06, 2000 at 01:32:10AM +, Jim Breton wrote: > Simple question: are suid/sgid shell scripts allowed in Linux? no, the kernel ignores s[ug]id bits on scripts. > I thought they were, but after I tried writing one and running it, it > appears that they are not. yup > Is the elevated privilege dropped back to normal by bash, or by the > kernel itself? kernel it never grants elevated privileges. > (I am aware of the security issues, I just want to know the answer to > this). the security issues are twofold, first there is a race condition between which the kernel read the interpreter line and execs /bin/sh (or whatever) to run the script, it could be replaced by then... (this is solvable by using /dev/fd or something) but there are also endless games users can play to trick the script into doing evil things. better option is perl+suidperl or a C program. perl at least provides a way to write secure suid scripts. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZWH5UZFaSE.pgp Description: PGP signature
Re: bind running as root in Mandrake 7.0
On Mon, Jun 05, 2000 at 12:59:36PM +0100, Zak Kipling wrote: > On Mon, 5 Jun 2000, Ethan Benson wrote: > > > idiots should not be running bind. > > Very true. But we can't very well have an install script which asks "Are > you an idiot?" and aborts installation if the user answers "Yes" ;-) > Bottom line is idiots *will* run bind anyway (after all they are > idiots...) So better that the default mode should be (relatively) safe, > requiring active intervention (and presumably knowledge) to open the big > holes like running it as root -- which as has already been pointed out is > only likely to be desirable for a very small minority of users. i completly agree, that is bind should be installed defaulting to running as named.named (which should be in the base-passwd btw) and probably chrooted as well. anyone needing a less secure configuration should know how to edit the initscripts and config files themselves with thier $EDITOR. i don't think it is necessary (or really desirable) to have the postinst asking about running bind as root, i think that the number of people who need it is far to small to justify ya interuption in the system install. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpN6SYzik4Fc.pgp Description: PGP signature
Re: bind running as root in Mandrake 7.0
On Mon, Jun 05, 2000 at 01:47:08PM +0200, Marco Giardini wrote: > On Mon, Jun 05, 2000 at 03:45:07AM -0800, Mr.Ethan Benson wrote: > > > > fwiw, OpenBSD by default installs an audited bind 4 configured to run > > non-root in a chroot jail. i presume they don't use bind 8 becuase it > > probably needs to be 110% rewritten to make it secure... > OpenBSD 2.6 install Bind 8 chrooted and as non root user. bzzt wrong thanks for playing. OpenBSD 2.6 ships with bind 4 installed, you can install bind 8 from /usr/ports if you wish to give up security, but the default installed version is still 4: named[29409]: starting. named 4.9.7-REL Thu May 21 19:27:54 1998 $ uname -mrs OpenBSD 2.6 i386 $ i am not sure about 2.7 but i doubt its any different. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpzNJYXg53Rl.pgp Description: PGP signature
