Re: Kernal Panic
On Thu, 31 May 2001, Dan Hutchinson wrote: > request-module[block-major-8]: Root fs not mounted. > VFS: Cannot open root device "801" or 08:01 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 08:01 This is way off-topic on debian-security, but: This suggests your new kernel is failing to find /dev/sda. Does the boot sequence mention anywhere that it's detected your SCSI interface (host adapter)? If not, do a "make menuconfig" and check the SCSI configuration to make sure support for your SCSI hardware is being compiled into the kernel (NOT as a module, since modules are not available till after the root fs is mounted). HTH, Zak.
Re: Kernal Panic
On Thu, 31 May 2001, Dan Hutchinson wrote: > request-module[block-major-8]: Root fs not mounted. > VFS: Cannot open root device "801" or 08:01 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 08:01 This is way off-topic on debian-security, but: This suggests your new kernel is failing to find /dev/sda. Does the boot sequence mention anywhere that it's detected your SCSI interface (host adapter)? If not, do a "make menuconfig" and check the SCSI configuration to make sure support for your SCSI hardware is being compiled into the kernel (NOT as a module, since modules are not available till after the root fs is mounted). HTH, Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Wed, 30 May 2001, Jon Leonard wrote: > I'm not aware of any actual implementations, unfortunately. http://www.mcdonald.org.uk/StegFS/
Re: root fs/crypted
On Tue, 29 May 2001 [EMAIL PROTECTED] wrote: > I see it as more than this. I see it as ensuring that the data on the disk > does > not get accessed by anyone never intended to see it. (physically, of course). > I guess this would mostly be cool for thwarting things like police raids, Although in some countries (eg Britain) you can be required by law to disclose the decryption keys, and imprisoned if you fail to do so. The only way around this is to use a steganographic approach where, in the absence of the passphrase for a given set of data, it is impossible even to prove its existence. (I have in the past used StegFS, although it didn't seem stable enough for critical use, and it doesn't work on 2.4 kernels yet. However, it seemed a very promising concept.) > servers vulnerable in remote locations (e.g. colocation, etc). My opinion is, > with privacy, you can never have too much. Very true, although a *false* sense of privacy can of course be worse than none at all -- so it is important that any such system is implemented with a lot of forethought. Just my 2p worth... Zak.
Re: root fs/crypted
On Wed, 30 May 2001, Jon Leonard wrote: > I'm not aware of any actual implementations, unfortunately. http://www.mcdonald.org.uk/StegFS/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Tue, 29 May 2001 [EMAIL PROTECTED] wrote: > I see it as more than this. I see it as ensuring that the data on the disk does > not get accessed by anyone never intended to see it. (physically, of course). > I guess this would mostly be cool for thwarting things like police raids, Although in some countries (eg Britain) you can be required by law to disclose the decryption keys, and imprisoned if you fail to do so. The only way around this is to use a steganographic approach where, in the absence of the passphrase for a given set of data, it is impossible even to prove its existence. (I have in the past used StegFS, although it didn't seem stable enough for critical use, and it doesn't work on 2.4 kernels yet. However, it seemed a very promising concept.) > servers vulnerable in remote locations (e.g. colocation, etc). My opinion is, > with privacy, you can never have too much. Very true, although a *false* sense of privacy can of course be worse than none at all -- so it is important that any such system is implemented with a lot of forethought. Just my 2p worth... Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: port 812
On Sun, 27 May 2001, Daniel Faller wrote: > I did a nmap scan (nmap -sT hostname) and found several ports open. The only > one I could not identify was 812. Have you tried "netstat -tp" or "fuser -vn tcp 812" on the machine in question to find out what process is listening on it? That's usually how I track them down... Zak.
Re: port 812
On Sun, 27 May 2001, Daniel Faller wrote: > I did a nmap scan (nmap -sT hostname) and found several ports open. The only > one I could not identify was 812. Have you tried "netstat -tp" or "fuser -vn tcp 812" on the machine in question to find out what process is listening on it? That's usually how I track them down... Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: proftpd exploit??
On Thu, 24 May 2001, Andres Herrera wrote: > I've tried to exploit it by login and sending: > ls ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../ > and suddenly it began eating memory and getting slow all the system. ... > Any solution?? Resource limits on the ftp server process? Zak.
Re: proftpd exploit??
On Thu, 24 May 2001, Andres Herrera wrote: > I've tried to exploit it by login and sending: > ls ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../ > and suddenly it began eating memory and getting slow all the system. ... > Any solution?? Resource limits on the ftp server process? Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secure install
On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote: > i am sure that is note the case, > the only requirement is that the target media is the > same size or larger? Indeed. Most filesystems, including ext2, are independent of the disk geometry. So you can "dd" _partitions_ (eg /dev/hda1) from smaller to larger disks, then add additional partitions if you want to take advantage of the extra space. The geometry is only relevant is you want to "dd" entire disks (eg /dev/hda). Alternatively you can tar the whole system -- slightly more work, but allows you to unpack on a differently-sized partition. Zak Kipling Girton College Cambridge, UK.
Re: secure install
On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote: > i am sure that is note the case, > the only requirement is that the target media is the > same size or larger? Indeed. Most filesystems, including ext2, are independent of the disk geometry. So you can "dd" _partitions_ (eg /dev/hda1) from smaller to larger disks, then add additional partitions if you want to take advantage of the extra space. The geometry is only relevant is you want to "dd" entire disks (eg /dev/hda). Alternatively you can tar the whole system -- slightly more work, but allows you to unpack on a differently-sized partition. Zak Kipling Girton College Cambridge, UK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Extremely simple MTA
On Thu, 14 Dec 2000, Stefan Melcher wrote: > try "nullmailer" from Bruce Guenter > http://em.ca/~bruceg/nullmailer/ Or ssmtp. (There are Debian packages of both.) Zak.
RE: Extremely simple MTA
On Thu, 14 Dec 2000, Stefan Melcher wrote: > try "nullmailer" from Bruce Guenter > http://em.ca/~bruceg/nullmailer/ Or ssmtp. (There are Debian packages of both.) Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-root loopback crypto
On Mon, 6 Nov 2000, Mike Furr wrote: > I've been using the loopback crypto stuff for a while and I'm looking > for a secure way of doing this from my user account instead of having to > su to call losetup. > Does anyone have suggestions / experience with doing this? Add an entry such as: /home/user/crypt.bin /home/user/crypt ext2 \ defaults,noauto,user,loop,encryption=blowfish 0 0 to /etc/fstab. Then you can run the command "mount /home/user/crypt" as non-root, provided you have appropriate permissions on /home/user/crypt.bin and /home/user/crypt.
Re: non-root loopback crypto
On Mon, 6 Nov 2000, Mike Furr wrote: > I've been using the loopback crypto stuff for a while and I'm looking > for a secure way of doing this from my user account instead of having to > su to call losetup. > Does anyone have suggestions / experience with doing this? Add an entry such as: /home/user/crypt.bin /home/user/crypt ext2 \ defaults,noauto,user,loop,encryption=blowfish 0 0 to /etc/fstab. Then you can run the command "mount /home/user/crypt" as non-root, provided you have appropriate permissions on /home/user/crypt.bin and /home/user/crypt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: something on port 98?
On Fri, 13 Oct 2000, Bradley M Alexander wrote: >Filtered means that a firewall, filter, or other network obstacle >is covering the port and preventing nmap from determining whether >the port is open. > > Are you running IPchains that is specifically blocking port 98? That would > make sense for an IPchains firewall to block port 98 out of the box since > you wouldn't want linuxconf access to the Internet at large. Getting a > connection refused is okay too from localhost: Could there be a router between you and the remote machine which blocks port 98? If I port-scan my own machine (on a university network) from a host outside the university, then several port are listed as "filtered" -- some of which I know are open, and some I know are closed. These are all caused by port blocks on the university's external routers. Might something similar be the case here? HTH, Zak.
Re: something on port 98?
On Fri, 13 Oct 2000, Bradley M Alexander wrote: >Filtered means that a firewall, filter, or other network obstacle >is covering the port and preventing nmap from determining whether >the port is open. > > Are you running IPchains that is specifically blocking port 98? That would > make sense for an IPchains firewall to block port 98 out of the box since > you wouldn't want linuxconf access to the Internet at large. Getting a > connection refused is okay too from localhost: Could there be a router between you and the remote machine which blocks port 98? If I port-scan my own machine (on a university network) from a host outside the university, then several port are listed as "filtered" -- some of which I know are open, and some I know are closed. These are all caused by port blocks on the university's external routers. Might something similar be the case here? HTH, Zak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: recent gpm DoS issue
On Fri, 28 Jul 2000, Jim Breton wrote: > 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. Isn't that /dev/gpmdata? -- Zak Kipling, Girton College, Cambridge. "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi
Re: recent gpm DoS issue
On Fri, 28 Jul 2000, Jim Breton wrote: > 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. Isn't that /dev/gpmdata? -- Zak Kipling, Girton College, Cambridge. "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SMB passwords etc (was "How can I help ?")
On Wed, 14 Jun 2000, Sebastian Rittau wrote: >> [stuff about encrypted SMB passwords] > > But using this option prevents you from using the global /etc/shadow > file, which is problematic in some cases. True. Samba has a "password sync" option to enable SMB password changes to automatically update the unix password file too (though it can be troublesome to get this working smoothly...) I'm no PAM or SMB expert, but I would imagine (if it hasn't been done) it would be feasible to make a stacked "password" module to do the reverse, ie to update the SMB password (including optionally creating the entry in the smbpasswd file if it doesn't exist) when the "passwd" command is used to change the unix password. A mechanism would obviously be required to prevent a loop situation when both options are used simultaneously. If Samba carried out the actual SMB password update via PAM, then this should allow for the required flexibiliity, with either one or both off the unix/SMB password setting modules used by passwd and smbd as desired. This would hopefully eliminate the need for the "password sync" option with its dependence on the precise prompt string produced by the "passwd" command. -- Zak Kipling, E114 Wolfson Court, Clarkson Road, Cambridge, CB3 0EH. Tel. (01223) 509524; pager 04325 361627; ICQ# 62661452; Ask for PGP key Internet chat: telnet to zk201.girton.cam.ac.uk and log in as "talk". "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi
SMB passwords etc (was "How can I help ?")
On Wed, 14 Jun 2000, Sebastian Rittau wrote: >> [stuff about encrypted SMB passwords] > > But using this option prevents you from using the global /etc/shadow > file, which is problematic in some cases. True. Samba has a "password sync" option to enable SMB password changes to automatically update the unix password file too (though it can be troublesome to get this working smoothly...) I'm no PAM or SMB expert, but I would imagine (if it hasn't been done) it would be feasible to make a stacked "password" module to do the reverse, ie to update the SMB password (including optionally creating the entry in the smbpasswd file if it doesn't exist) when the "passwd" command is used to change the unix password. A mechanism would obviously be required to prevent a loop situation when both options are used simultaneously. If Samba carried out the actual SMB password update via PAM, then this should allow for the required flexibiliity, with either one or both off the unix/SMB password setting modules used by passwd and smbd as desired. This would hopefully eliminate the need for the "password sync" option with its dependence on the precise prompt string produced by the "passwd" command. -- Zak Kipling, E114 Wolfson Court, Clarkson Road, Cambridge, CB3 0EH. Tel. (01223) 509524; pager 04325 361627; ICQ# 62661452; Ask for PGP key Internet chat: telnet to zk201.girton.cam.ac.uk and log in as "talk". "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bind running as root in Mandrake 7.0
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. -- Zak Kipling, E114 Wolfson Court, Clarkson Road, Cambridge, CB3 0EH. Tel. (01223) 509524; pager 04325 361627; ICQ# 62661452; Ask for PGP key Internet chat: telnet to zk201.girton.cam.ac.uk and log in as "talk". "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi
Re: Tripwire in bin-directory?
On Wed, 24 May 2000, Thomas Guettler wrote: > Isn't it a security risk, that there > is a shellscript in bin that executes /usr/lib/tripwire. > If someone breaks into my system, he/she could > change the file in bin to something that always > reports that nothing was changed! If someone breaks into your system, he/she could change /usr/lib/tripwire itself... isn't this just as much of a problem, except in the unlikely event that /usr/lib is hardware write-protected while /bin is not. -- Zak Kipling, Girton College, Cambridge, England. "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi
Re: Sendmail
On 27 Mar 2000, Brian May wrote: > I think some programs use port 25 for outgoing mail, too (netscape? > pine? mh?). True. In which case block port 25 on all _external_ interfaces (eth0, ppp0 etc) but leave it open on the loopback interface. -- Zak Kipling. "As long as the superstition that people should obey unjust laws exists, so long will slavery exist." -- M. K. Gandhi
