Done: [SECURITY] [DSA 2290-1] samba security update
-- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e3f7e6c@tugraz.at
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, this is standard for me. I always change the port of the openSSH-server. My (current) solution is: Portsentry listens on port 22, while openSSH-server has another port. Every port scan attempt will result in a ban via iptables and every connection to port 22 will also result in a ban via iptables. Regards Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Clemens Pfaffinger > Hi, > > this is standard for me. I always change the port of the openSSH-server. > > My (current) solution is: > Portsentry listens on port 22, while openSSH-server has another port. > Every port scan attempt will result in a ban via iptables and every > connection to port 22 will also result in a ban via iptables. > > Regards > > Kontaktinformationen > clem...@csrv.at > www.cdev.at > > > 2009/7/7 Leandro Minatel > >> Hi, >> >> a good practice, at least for me, is put openssh to listen in a different >> port than the default. I know, it's not the perfect solution. >> >> Regards. >> > >
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, thanks for this information! I just hope that this is a hoax. What would you suggest for securing a server running openSSH? How can I notice such an attack in my log files? Cheers Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Henrique de Moraes Holschuh > As usual, you may want to either raise shields (i.e. disable/restrict > access > to the ssh service), or pay extra attention to what is happening on your > SSH > inbound gateways... > > http://lwn.net/Articles/340360/ > http://isc.sans.org/diary.html?storyid=6742 > http://secer.org/hacktools/0day-openssh-remote-exploit.html > > Yes, it could be a hoax, and I sure hope that's all it is... > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > > -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > >
debian testing Packages.bz2 md5 sum mismatch
hi, today (2006/07/27) I found out that the Packages.bz2 md5sum for binary-i386 in the testing tree does not match the one in the Release file. from the Release file: a69180e606d62bda995f51d7b92d2e2e 18168746 main/binary-i386/Packages bd5ab126b3006a34b1f95cacc3a584bc 5340646 main/binary-i386/Packages.gz fc0ba1c802c00e1c087a521d5eb6336c 4068980 main/binary-i386/Packages.bz2 30ab1ba2a9c09d1850f7a40b639624b3 81 main/binary-i386/Release from the directory: a69180e606d62bda995f51d7b92d2e2e 18168746 main/binary-i386/Packages bd5ab126b3006a34b1f95cacc3a584bc 5340646 main/binary-i386/Packages.gz ff9c387de3374600452a06e3449bf364 4037187 main/binary-i386/Packages.bz2 30ab1ba2a9c09d1850f7a40b639624b3 81 main/binary-i386/Release as you can see only the bz2 is different. It doesn't seem to throw an error on my local boxes that use my apt-proxy server where I found those files. But another box I sync the apt-proxy directory and where I have to "local" use file:/ for the apt settings, complains about the mismatch in the md5 sum. I hope there is no serious issue goeing on -- [ Clemens Schwaighofer -=:~ ] [ TEQUILA\ Japan IT Group] [6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp ] signature.asc Description: OpenPGP digital signature
DM-Crypt and PAM Mount
Hi fellow Debian users, I just got the combination of a dm encrypted FS with the PAM mount ability working. What gave me quite a headache was the following: You can use the PAM mount lib to encrypt your mantra of the dm encrypted partition with your login password. I started out with a rather long (2880 Bytes) dm mantra. I generated it by something like: head -c 2880 /dev/random | uuencode -m -| head -n 65 | tail -n 64 > /home/clemens.key Afterwards, I set everything up as it is explained in /usr/share/doc/libpam-mount/README.Debian.gz always ending up with the following log file entries: Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: (defined by globalconf) Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: user: clemens Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: server: Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: volume:/dev/hdb7 Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: mountpoint:/mnt/dm/ Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: options: cipher=twofish,hash=sha512 Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: fs_key_cipher: aes-256-ecb Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: fs_key_path: /home/clemens.key Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: use_fstab: 0 Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: checking to see if /dev/mapper/_dev_hdb7 is already mounted at /mnt/dm/ Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: checking for encrypted filesystem key configuration Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: decrypting FS key using system auth. token and aes-256-ecb Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: bad pad on end of encrypted file (wrong algorithm or key size?) Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: mount of /dev/hdb7 failed Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: checking sanity of volume record (/dev/hdb7) Nov 7 00:48:25 zappa kdm: :0[11226]: pam_mount: about to perform mount operations So, I am not quite sure where the cut off happens: a) in the openssl package while the mantra file gets decrypted b) in the dmsetup package when setting up the device mapper file Everything works fine when I use shorter passwords. Since I could not find any documentation stating this problem, I address this issue here to the list. Am I missing something? Thanks for your comments and explanations. Clemens Bier -- GPG Key: http://eigenvalue.net/~clemens/gpgkey.asc Fingerprint: 1024D/A07D0D1B 5FB1 B155 8070 DF8B 4350 6583 87FF 3589 A07D 0D1B signature.asc Description: This is a digitally signed message part
Re: USB Stick, GPG and CryptoFS in a startup script
On Thu, 2004-04-29 at 00:11, Hubert Chan wrote: > >>>>> "Clemens" == Clemens Bier <[EMAIL PROTECTED]> writes: > > [...] > > Clemens> So, now we come to the point: When I integrate my script into > Clemens> /etc/init.d as one of the startup scripts, I get the following > Clemens> error message during boot time cannot open '/dev/tty' : > Clemens> no such device or address Error: Password must be at least 20 > Clemens> characters > > Have you tried adding the --no-tty option to gpg? > If I replace the current gpg command with this: gpg --no-tty --no-options --decrypt /mnt/stick/key.gpg I get the following error message even when executing the script in a console: gpg: Sorry, no terminal at all requested - can't get input So, I did not try this during boot time. Concerning the second suggestion using the --passphrase-fd option to gpg does not work either and I get the same old message during boot time as above. Any other hints? Thanks and a nice weekend, Clemens signature.asc Description: This is a digitally signed message part
Re: USB Stick, GPG and CryptoFS in a startup script
On Thu, 2004-04-29 at 00:11, Hubert Chan wrote: > >>>>> "Clemens" == Clemens Bier <[EMAIL PROTECTED]> writes: > > [...] > > Clemens> So, now we come to the point: When I integrate my script into > Clemens> /etc/init.d as one of the startup scripts, I get the following > Clemens> error message during boot time cannot open '/dev/tty' : > Clemens> no such device or address Error: Password must be at least 20 > Clemens> characters > > Have you tried adding the --no-tty option to gpg? > If I replace the current gpg command with this: gpg --no-tty --no-options --decrypt /mnt/stick/key.gpg I get the following error message even when executing the script in a console: gpg: Sorry, no terminal at all requested - can't get input So, I did not try this during boot time. Concerning the second suggestion using the --passphrase-fd option to gpg does not work either and I get the same old message during boot time as above. Any other hints? Thanks and a nice weekend, Clemens signature.asc Description: This is a digitally signed message part
Re: USB Stick, GPG and CryptoFS in a startup script
Hallo Goswin, Goswin von Brederlow schrieb: Clemens Bier <[EMAIL PROTECTED]> writes: cannot open '/dev/tty' : no such device or address Error: Password must be at least 20 characters I think you need to redirect input from /dev/tty or /dev/console explicitly or you need to setup an utmp entry first (like login would do). Could you explain more precisely what you mean by utmp and /or explicit redirecting? Looking at the line that starts with gpg, I try to redirect the input from /dev/console. But I still ge the same error. I do also get a "cannot open '/dev/tty' : no such device or address" if I insert a debug statement like 'echo "Debug" > /dev/tty' into my script. Thanks, Clemens
Re: USB Stick, GPG and CryptoFS in a startup script
Hallo Goswin, Goswin von Brederlow schrieb: Clemens Bier <[EMAIL PROTECTED]> writes: cannot open '/dev/tty' : no such device or address Error: Password must be at least 20 characters I think you need to redirect input from /dev/tty or /dev/console explicitly or you need to setup an utmp entry first (like login would do). Could you explain more precisely what you mean by utmp and /or explicit redirecting? Looking at the line that starts with gpg, I try to redirect the input from /dev/console. But I still ge the same error. I do also get a "cannot open '/dev/tty' : no such device or address" if I insert a debug statement like 'echo "Debug" > /dev/tty' into my script. Thanks, Clemens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
USB Stick, GPG and CryptoFS in a startup script
Hi to all Debian friends, I am posting my problem to this list since I am sort of clueless. I have the following problem: I have a dedicated partition which I use with cryptoloop (yes, I know dm-crypt is out there) and a AES cipher. Mounting and unmounting the partition works fine with all 2.6 Kernels. Thus I enhanced my setup by placing the key for encryption and decryption of the partition as a file on my USB Stick. I additionally symmetrically encrypt the key file with gpg. I have put all of this in a small shell script (see attachment). Using this script as root after the login works flawlessly. So, now we come to the point: When I integrate my script into /etc/init.d as one of the startup scripts, I get the following error message during boot time cannot open '/dev/tty' : no such device or address Error: Password must be at least 20 characters I have already put some debug commands into my script to do a ls on the tty device. This looks like the following: ls -al /dev/tty crw-rw-rw-1 root tty5, 0 Apr 27 21:29 /dev/tty ls -al /dev/tty0 crw---1 root root 4, 0 Apr 9 10:34 /dev/tty0 As far as I could figure out, the init script /etc/init.d/bootmisc.sh sets the permissions on the tty device. I am still a noobie to Kernel internals. Thus I am not sure where to look for further clues. Thanks for any tips or hints. Have a nice day Clemens Bier #!/bin/sh -e case "$1" in start) /sbin/modprobe sd_mod /sbin/modprobe usb-storage /sbin/modprobe cryptoloop /sbin/modprobe aes /bin/mount -t ext2 /dev/sda2 /mnt/iriver gpg --no-options --decrypt /mnt/key/key.gpg < /dev/console | /sbin/losetup -e AES128 /dev/loop0 /dev/hdb7 -p 0 /bin/mount -o defaults,users /dev/loop0 /crypto /bin/umount /dev/sda ;; stop) /bin/umount /dev/loop0 /sbin/losetup -d /dev/loop0 ;; esac signature.asc Description: This is a digitally signed message part
USB Stick, GPG and CryptoFS in a startup script
Hi to all Debian friends, I am posting my problem to this list since I am sort of clueless. I have the following problem: I have a dedicated partition which I use with cryptoloop (yes, I know dm-crypt is out there) and a AES cipher. Mounting and unmounting the partition works fine with all 2.6 Kernels. Thus I enhanced my setup by placing the key for encryption and decryption of the partition as a file on my USB Stick. I additionally symmetrically encrypt the key file with gpg. I have put all of this in a small shell script (see attachment). Using this script as root after the login works flawlessly. So, now we come to the point: When I integrate my script into /etc/init.d as one of the startup scripts, I get the following error message during boot time cannot open '/dev/tty' : no such device or address Error: Password must be at least 20 characters I have already put some debug commands into my script to do a ls on the tty device. This looks like the following: ls -al /dev/tty crw-rw-rw-1 root tty5, 0 Apr 27 21:29 /dev/tty ls -al /dev/tty0 crw---1 root root 4, 0 Apr 9 10:34 /dev/tty0 As far as I could figure out, the init script /etc/init.d/bootmisc.sh sets the permissions on the tty device. I am still a noobie to Kernel internals. Thus I am not sure where to look for further clues. Thanks for any tips or hints. Have a nice day Clemens Bier #!/bin/sh -e case "$1" in start) /sbin/modprobe sd_mod /sbin/modprobe usb-storage /sbin/modprobe cryptoloop /sbin/modprobe aes /bin/mount -t ext2 /dev/sda2 /mnt/iriver gpg --no-options --decrypt /mnt/key/key.gpg < /dev/console | /sbin/losetup -e AES128 /dev/loop0 /dev/hdb7 -p 0 /bin/mount -o defaults,users /dev/loop0 /crypto /bin/umount /dev/sda ;; stop) /bin/umount /dev/loop0 /sbin/losetup -d /dev/loop0 ;; esac signature.asc Description: This is a digitally signed message part
Secpack update for 2004 key.
Hi! I have updated secpack with the new keys for 2004. http://clemens.endorphin.org/secpack/ secpack implements updates from security.debian.org with signature checking. To Maria: secpack has never been part of Debian, since I'm not an official Debian developer. If someone wants to take care of this package, please speak out. Regards, Clemens P.S.: I'm sorry that this update took me so long, but I lost interest in using Debian because of it's release cycles. No offense. pgpemWoxwyrvo.pgp Description: PGP signature
Secpack update for 2004 key.
Hi! I have updated secpack with the new keys for 2004. http://clemens.endorphin.org/secpack/ secpack implements updates from security.debian.org with signature checking. To Maria: secpack has never been part of Debian, since I'm not an official Debian developer. If someone wants to take care of this package, please speak out. Regards, Clemens P.S.: I'm sorry that this update took me so long, but I lost interest in using Debian because of it's release cycles. No offense. pgp0.pgp Description: PGP signature
secpack update - Automatic security updates
An update to secpack is available with the new Debian ftp archive key. http://therapy.endorphin.org/secpack/ secpack implements updates from security.debian.org with signature checking. I'm no official debian developer. Does anyone want to adopt this unofficial package? Regards, Clemens
secpack update - Automatic security updates
An update to secpack is available with the new Debian ftp archive key. http://therapy.endorphin.org/secpack/ secpack implements updates from security.debian.org with signature checking. I'm no official debian developer. Does anyone want to adopt this unofficial package? Regards, Clemens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic Debian security updates, an Implementation
On Fri, 2002-10-18 at 09:55, Gustavo Franco wrote: > Talking about secpack, is it non-free? I can't see in your mail(Clemens) > the url or apt-line to get the source package. No, it's BSD. I didn't dare to put up a license for that minimal collection. There isn't even a source package. I just dpkg-deb -b the few files with a DEBIAN/control file. See http://therapy.endorphin.org/secpack/ Regards, Clemens P.S.: Sorry for replying that late, but someone obviously removed my Cc line and I haven't been subscribed to debian-security. Just found your message accidently in the archives. pgp8f9gk5X81C.pgp Description: PGP signature
Re: Automatic Debian security updates, an Implementation
On Fri, 2002-10-18 at 09:55, Gustavo Franco wrote: > Talking about secpack, is it non-free? I can't see in your mail(Clemens) > the url or apt-line to get the source package. No, it's BSD. I didn't dare to put up a license for that minimal collection. There isn't even a source package. I just dpkg-deb -b the few files with a DEBIAN/control file. See http://therapy.endorphin.org/secpack/ Regards, Clemens P.S.: Sorry for replying that late, but someone obviously removed my Cc line and I haven't been subscribed to debian-security. Just found your message accidently in the archives. msg07844/pgp0.pgp Description: PGP signature
Automatic Debian security updates, an Implementation
Hi! http://therapy.endorphin.org/secpack_0.1-1.deb implements a simple cron based daily security update with signature checking using a modified version of ajt's apt-check-sigs. Feedback is appreciated. CC please, /me not on list. Regards, Clemens pgpVBkwjvCD5f.pgp Description: PGP signature
Automatic Debian security updates, an Implementation
Hi! http://therapy.endorphin.org/secpack_0.1-1.deb implements a simple cron based daily security update with signature checking using a modified version of ajt's apt-check-sigs. Feedback is appreciated. CC please, /me not on list. Regards, Clemens msg07424/pgp0.pgp Description: PGP signature
CryptoAPI: Need beta-testers.
Hi! I'm happy to announce out-of-the-box support for CryptoAPI on woody on i386. No need to touch source code, nor kernel patches. Just put deb http://therapy.endorphin.org/cryptoapi/ ./ into your sources.list and depending on your kernel flavor apt-get install cryptoapi-core-2.4.18-[386|586|586tsc|686...] apt-get install cryptoloop-2.4.18-[386|586|586tsc|686...] That's it, no need to reboot. "modprobe cryptoloop" and you're done. For those that are blessed with a non-i386 architecture or that use self made kernels, there are - of course - source packages. Same sources.list line, but apt-get install cryptoapi-core-src cryptoloop-src CryptoAPI depends on the kernel building system, therefor it won't without the kernel source. After make-kpkg binary-arch just make-kpkg modules_image and cryptoapi-core and cryptoloop will be built fitting your kernel version. Although I have done my best to get this stuff working properly I recommend that you consider these packages HIGHLY EXPERIMENTAL. Do NOT use in production environment (I'm serious!). In case you have access to a Debian box running on a non-i386 architecture, please contact me. For further information on how to use cryptoloop have a look at http://www.kerneli.org/cryptoapi/howto/ This is not yet an official CryptoAPI release. Feedback is highly appreciated, Clemens pgp5PDshCYwtC.pgp Description: PGP signature
Re: root fs/crypted
it should also be possible to include basic network support into the initrd to enable 'entering' a password remote. we can't support all methods allowed by /etc/network/interfaces (ppp/wvdial should be omitted..) but static/dhcp/bootp are possible. there authorization process could beneath reading /dev/console also listen on an udp port. local and remote station must share a secret(key) to allow secure communication. a couple of one time pads for maximum security would be the best. i don't want to drive through the whole city because someone accidentally unplugged my box :) On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote: > > SAWFASP^* > > as laws around the globe are forged to weak personal privacy, > police knocking on one's door, because of portscanning a > previously hacked website, and - i don't have to tell those > of you, which are reading slashdot - as pretty strange things start > to happend worldwide, i'm getting somewhat nervous about > my data safety. > > what i'm aiming at, you might ask? > debian should support a crypted rootfs right out > of the box. > > i'll try to grasp within a few words, what's necessary to realize this: > > - the international kernel must be introduced as regular > debian packages. > - the boot disks needs to be modified (just do a losetup > on some loopdev, and mount that one instead of the realrootdev) > - of course, there must be an initrd to boot from, > which accepts authentication information. > (this ramdisk has to be placed unencrypted on >the rootfs, so the kernel code has to be circumwented or >the plain data has to be manually decrypted in usermode >to be re-encrypted to the original plain data when flushed >to disk.. easy for EBC mode crypto but harder to >achieve for CBC mode - creative suggestions welcome) > - there must be an alternative passphrase, since i nor > any user will be willing to trust one forgetable phrase. > (how many times have you forgotten your mobil phone pin?) > suggestion: the actual key will be random generated, and > encrypted twice by two different passphrases/keys - one > choosen by the user, one random generated - useful to write on > a piece of paper and hide behind the bookshelf. > > (probably i should crosspost to debian-legal. the > whole non-US issue has been left untouched) > > what do YOU think? > shell debian be the first(?) privacy enhanced distro? > > clemens > > ^* SAWFASP = searched archives without finding a similiar > posting
Re: root fs/crypted
On Wed, May 30, 2001 at 12:17:35PM +0900, Curt Howland wrote: > [cut] > but that only works at startup. if the system is running, > having the entire disk encrypted is no different than the > fact it's all in hex already. an individual user based > encryption means all you have to do is logout, not power > down, to kill the "decryption" process and thwart snooping. > > so how about a start-up passphrase protecting everything > owned by root, then another for each individual user? but > that would cancel root's ability to read everything we should not aim to protect root from accessing userdata. user must trust root. root could replace losetup by a malicious logging one. this double keying makes sence, in the usual raided-case. (the rootfs could reside on an encrypting loop device, the user homedirs could reside as image files on an unencrypted secondary partition, although we lose the feature of dynamic space allocation, since these user files are images with static file sizes. cfs is much more usefull for user encryption, but much slower). cle
Re: root fs/crypted
On Tue, May 29, 2001 at 08:02:50PM -0700, Paul Lowe wrote: > I like this. Would it be difficult to modify Debian, so that > upon install, it creates an encrypted root volume and starts > things off the right way? 3 things are needed to that upon installation: - losetup -e /dev/loop0 /dev/ (for further actions set rootdev to /dev/loop0) - kerneli (see http://kerneli.org) - copy a standard initrd to the root disk, and add it to the lilo parameters. looks promising, doesn't it? cle
Re: root fs/crypted
On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote: > On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote: > > Couldn't you say something like "I'm so sorry, I can't remember the pass > > phrase, my mind has failed me...etc?" > What about a more provable approach: > > The passphrase could be changed automatically on every system > boot, and the new passphrase could be written to a floppy disk > on a clean shutdown (which, of course, is only possible with > the root password). > > So if the police takes the computer and doesn't do the clean > shutdown (how could they?), you can tell them: Sorry folks, > you just destroyed the possibility to get any data from that computer... > > This, of course, means that you lose your data if the computer > crashes. if there would be two keys to the system (the way i described in my original posting) the user key could be written to disc only on clean shutdown. so if the system is unplugged by law enforcement, the key you know is unusable. under truth serums are whatever you can rightfully assert you don't know the key. (you don't know the alternative random generated key either, but you know it's behind the bookshelf written on a piece of paper). but that belongs to debian-legal. cle
Re: root fs/crypted
it should also be possible to include basic network support into the initrd to enable 'entering' a password remote. we can't support all methods allowed by /etc/network/interfaces (ppp/wvdial should be omitted..) but static/dhcp/bootp are possible. there authorization process could beneath reading /dev/console also listen on an udp port. local and remote station must share a secret(key) to allow secure communication. a couple of one time pads for maximum security would be the best. i don't want to drive through the whole city because someone accidentally unplugged my box :) On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote: > > SAWFASP^* > > as laws around the globe are forged to weak personal privacy, > police knocking on one's door, because of portscanning a > previously hacked website, and - i don't have to tell those > of you, which are reading slashdot - as pretty strange things start > to happend worldwide, i'm getting somewhat nervous about > my data safety. > > what i'm aiming at, you might ask? > debian should support a crypted rootfs right out > of the box. > > i'll try to grasp within a few words, what's necessary to realize this: > > - the international kernel must be introduced as regular > debian packages. > - the boot disks needs to be modified (just do a losetup > on some loopdev, and mount that one instead of the realrootdev) > - of course, there must be an initrd to boot from, > which accepts authentication information. > (this ramdisk has to be placed unencrypted on >the rootfs, so the kernel code has to be circumwented or >the plain data has to be manually decrypted in usermode >to be re-encrypted to the original plain data when flushed >to disk.. easy for EBC mode crypto but harder to >achieve for CBC mode - creative suggestions welcome) > - there must be an alternative passphrase, since i nor > any user will be willing to trust one forgetable phrase. > (how many times have you forgotten your mobil phone pin?) > suggestion: the actual key will be random generated, and > encrypted twice by two different passphrases/keys - one > choosen by the user, one random generated - useful to write on > a piece of paper and hide behind the bookshelf. > > (probably i should crosspost to debian-legal. the > whole non-US issue has been left untouched) > > what do YOU think? > shell debian be the first(?) privacy enhanced distro? > > clemens > > ^* SAWFASP = searched archives without finding a similiar > posting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Wed, May 30, 2001 at 12:17:35PM +0900, Curt Howland wrote: > [cut] > but that only works at startup. if the system is running, > having the entire disk encrypted is no different than the > fact it's all in hex already. an individual user based > encryption means all you have to do is logout, not power > down, to kill the "decryption" process and thwart snooping. > > so how about a start-up passphrase protecting everything > owned by root, then another for each individual user? but > that would cancel root's ability to read everything we should not aim to protect root from accessing userdata. user must trust root. root could replace losetup by a malicious logging one. this double keying makes sence, in the usual raided-case. (the rootfs could reside on an encrypting loop device, the user homedirs could reside as image files on an unencrypted secondary partition, although we lose the feature of dynamic space allocation, since these user files are images with static file sizes. cfs is much more usefull for user encryption, but much slower). cle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Tue, May 29, 2001 at 08:02:50PM -0700, Paul Lowe wrote: > I like this. Would it be difficult to modify Debian, so that > upon install, it creates an encrypted root volume and starts > things off the right way? 3 things are needed to that upon installation: - losetup -e /dev/loop0 /dev/ (for further actions set rootdev to /dev/loop0) - kerneli (see http://kerneli.org) - copy a standard initrd to the root disk, and add it to the lilo parameters. looks promising, doesn't it? cle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote: > On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote: > > Couldn't you say something like "I'm so sorry, I can't remember the pass > > phrase, my mind has failed me...etc?" > What about a more provable approach: > > The passphrase could be changed automatically on every system > boot, and the new passphrase could be written to a floppy disk > on a clean shutdown (which, of course, is only possible with > the root password). > > So if the police takes the computer and doesn't do the clean > shutdown (how could they?), you can tell them: Sorry folks, > you just destroyed the possibility to get any data from that computer... > > This, of course, means that you lose your data if the computer > crashes. if there would be two keys to the system (the way i described in my original posting) the user key could be written to disc only on clean shutdown. so if the system is unplugged by law enforcement, the key you know is unusable. under truth serums are whatever you can rightfully assert you don't know the key. (you don't know the alternative random generated key either, but you know it's behind the bookshelf written on a piece of paper). but that belongs to debian-legal. cle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
root fs/crypted
SAWFASP^* as laws around the globe are forged to weak personal privacy, police knocking on one's door, because of portscanning a previously hacked website, and - i don't have to tell those of you, which are reading slashdot - as pretty strange things start to happend worldwide, i'm getting somewhat nervous about my data safety. what i'm aiming at, you might ask? debian should support a crypted rootfs right out of the box. i'll try to grasp within a few words, what's necessary to realize this: - the international kernel must be introduced as regular debian packages. - the boot disks needs to be modified (just do a losetup on some loopdev, and mount that one instead of the realrootdev) - of course, there must be an initrd to boot from, which accepts authentication information. (this ramdisk has to be placed unencrypted on the rootfs, so the kernel code has to be circumwented or the plain data has to be manually decrypted in usermode to be re-encrypted to the original plain data when flushed to disk.. easy for EBC mode crypto but harder to achieve for CBC mode - creative suggestions welcome) - there must be an alternative passphrase, since i nor any user will be willing to trust one forgetable phrase. (how many times have you forgotten your mobil phone pin?) suggestion: the actual key will be random generated, and encrypted twice by two different passphrases/keys - one choosen by the user, one random generated - useful to write on a piece of paper and hide behind the bookshelf. (probably i should crosspost to debian-legal. the whole non-US issue has been left untouched) what do YOU think? shell debian be the first(?) privacy enhanced distro? clemens ^* SAWFASP = searched archives without finding a similiar posting
root fs/crypted
SAWFASP^* as laws around the globe are forged to weak personal privacy, police knocking on one's door, because of portscanning a previously hacked website, and - i don't have to tell those of you, which are reading slashdot - as pretty strange things start to happend worldwide, i'm getting somewhat nervous about my data safety. what i'm aiming at, you might ask? debian should support a crypted rootfs right out of the box. i'll try to grasp within a few words, what's necessary to realize this: - the international kernel must be introduced as regular debian packages. - the boot disks needs to be modified (just do a losetup on some loopdev, and mount that one instead of the realrootdev) - of course, there must be an initrd to boot from, which accepts authentication information. (this ramdisk has to be placed unencrypted on the rootfs, so the kernel code has to be circumwented or the plain data has to be manually decrypted in usermode to be re-encrypted to the original plain data when flushed to disk.. easy for EBC mode crypto but harder to achieve for CBC mode - creative suggestions welcome) - there must be an alternative passphrase, since i nor any user will be willing to trust one forgetable phrase. (how many times have you forgotten your mobil phone pin?) suggestion: the actual key will be random generated, and encrypted twice by two different passphrases/keys - one choosen by the user, one random generated - useful to write on a piece of paper and hide behind the bookshelf. (probably i should crosspost to debian-legal. the whole non-US issue has been left untouched) what do YOU think? shell debian be the first(?) privacy enhanced distro? clemens ^* SAWFASP = searched archives without finding a similiar posting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ip spoofing (httpd)
Hi, today I had a discussion with somebody about the possibility of ip-spoofing that affects the apache. In particular we were talking about a cgi-script he implemented. The script is sort of an online-voting-system. To avoid that someone clicks several times he uses the source-IP and each IP has only got one vote. IMHO it should be quite easy to bypass this sort of "security" because the script evaluates a http-request (vote coded in the URL). Can anyone give me a code-example that does exactly this? tia /ch
ip spoofing (httpd)
Hi, today I had a discussion with somebody about the possibility of ip-spoofing that affects the apache. In particular we were talking about a cgi-script he implemented. The script is sort of an online-voting-system. To avoid that someone clicks several times he uses the source-IP and each IP has only got one vote. IMHO it should be quite easy to bypass this sort of "security" because the script evaluates a http-request (vote coded in the URL). Can anyone give me a code-example that does exactly this? tia /ch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
