safety of encrypted filesystems
Encrypted filesystems are hip these days, and that's good. One of the reasons why I have not jumped on the waggon is a concern about their safety. When using a block cipher such as AES or similar to encode e.g. a file of 1024 Mb, the blocks of the ciphertext are in relation to each other. This is accomplished using methods like CBC (Cipher Block Chaining, among others). The motivation here is to fend off statistical (and replay) attacks. Storage media these days are usually okay, but there have been times when a bad block on a disk, or a corrupt byte on a flash medium have caused trash to be returned for the block. Please correct me if I am wrong, but with a single file spanning 1 Gb of medium, chances are fairly high for such a bad block to happen within the file (given that it happens at all). If such a bad block occurs and renders a small part of the encrypted file unreadable, wouldn't the entire partition and all its data be effectively destroyed? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! ah, but a man's reach should exceed his grasp, or what's a heaven for? -- robert browning signature.asc Description: Digital signature
Re: Security Support by the Security-Team
* Helmut Toplizer: I'm also interested in other opinions as I can't suggest an already established best-practice. Use unstable or testing, and apply security fixes yourself. Over time, stable (with its historic software version) will drift considerably from upstream, which will make security support economically infeasible, so this is the only way that ensures you'll have access to security fixes in a reasonable timeframe. (This is not a Debian-specific problem, most distributors face the same issues.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
* martin f. krafft: Encrypted filesystems are hip these days, [...] Are they? I thought most of the fuzz was about encrypted block devices. If such a bad block occurs and renders a small part of the encrypted file unreadable, wouldn't the entire partition and all its data be effectively destroyed? A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). By the way, the very fact that the block is not lost completely indicates a major cryptographic weakness: there are no integrity checks at all. (The constant IV problem is another one.) These weaknesses don't matter in many scenarios, but it's still an undesirable situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0834 +0200]: Encrypted filesystems are hip these days, [...] Are they? I thought most of the fuzz was about encrypted block devices. That's what I mean. If such a bad block occurs and renders a small part of the encrypted file unreadable, wouldn't the entire partition and all its data be effectively destroyed? A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! DISCLAIMER: this entire message is privileged communication, intended for the sole use of its recipients only. If you read it even though you know you aren't supposed to, you're a poopy-head. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
* martin f. krafft: A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). Of course blocks are small, e.g. 64 bytes. These are *cipher* blocks, and they are chained only within a *block device* block. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 08:46:03 +0200 martin f krafft [EMAIL PROTECTED] wrote: Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? No. If it would be that way, it would allways be necessary to decrypt the whole filesystem, when you want to read the last block. Or you have to store a decrypted version in memory... And also, when you write any block, you have to reencrypt all the remaining blocks. I don't know, what kind of CPU you use, but on my system, that would be really time consuming!!! The loss of a single block on a harddist should be protected by using some kind of forward error correction like the Solomon-Reed one. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! friendships last when each friend thinks he has a slight superiority over the other. -- honor de balzac signature.asc Description: Digital signature
Re: safety of encrypted filesystems
* martin f. krafft: also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? For each device block, a constant, block-specific IV is used. Device blocks are not chained together. The block device doesn't know anything about files, anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:03:57 +0200 martin f krafft [EMAIL PROTECTED] wrote: Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? That is the reason, why a reasonable clever programmer would not do such a silly thing. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:02:05 +0200, martin f krafft writes: also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0835 +0200]: no - with cbd, dud blocks effect only decryption of the block itself and the one directly following it. ... and that one affects the one directly following it, and that one affects the one directly following it. no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. one dead block spills junk all over the block+1 when decrypted, but the (undamaged) encrypted block+1 is used to decrypt block+2 and so on. So if you have a corruption in the first block, your data are gone. If you have a corruption in the last block, the loss is minimal. no, see above. details (with a nice diagram) can be found on page 220 of the handbook of applied crypto. the official pdfs are here: URL:http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf regards az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpE1r4HTynPz.pgp Description: PGP signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 17:15:32 +1000, Alexander Zangerl writes: (bloody hell: can't even type anymore. weekend is calling...) also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0835 +0200]: no - with cbd, dud blocks effect only decryption of the block itself and the one directly following it. i meant cipher block chaining. no idea how i got to cbd. details (with a nice diagram) can be found on page 220 of the handbook of applied crypto. the official pdfs are here: URL:http://www.cacr.math.uwaterloo.ca/hac/about/c hap7.pdf page 229. argh. az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpy13gk1dyRq.pgp Description: PGP signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 17:15:32 +1000 Alexander Zangerl [EMAIL PROTECTED] wrote: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. That's a possible, but unsecure way to do that. This way, an attacker can try to decrypt any block x by using the encrypted block x-1 and guessing the passphrase. When knowing the structure of the filesystem, he will have a chance to find the passphrase in a reasonable time. When an attacher HAS TO decrypt the first block of a filesystem, AND this filesystem starts with a challenge (random data) in the first block and the real filesystem begins at the second block, there is no way to guess the passphrase, because the attacker cannot check, if the first block was decrypted correctly. If i had to build an encrypted filesystem, i would use clusters of i.e. 8kb, starting with a challenge (256 bytes), followed by data (7.5 kb), followed by error correction data (256 bytes). On every write, the first 7 3/4 kb will be encrypted and then the error-corrction code will we calculated for that data and stored in the last part of the cluster. I think, this will give good security with reasonable CPU-effort. -- mit freundlichen Gruessen / with friendly regards Michael BuchholzPhone.: +49 231 4755513 Paschknappstr. 13 Mobil.: +49 171 3111861 44265 Dortmund, Germany Fax...: +49 231 4755514 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.0857 +0200]: If it would be that way, it would allways be necessary to decrypt the whole filesystem, when you want to read the last block. Or you have to store a decrypted version in memory... No, it would not. You only need access to the immediately preceeding block, since its *cipherdata* are used to encrypt the current block. And also, when you write any block, you have to reencrypt all the remaining blocks. Yes, don't you? I don't know, what kind of CPU you use, but on my system, that would be really time consuming!!! Just one of those 100 GHz low-end consumer products with 128 cores. And you? :) The loss of a single block on a harddist should be protected by using some kind of forward error correction like the Solomon-Reed one. But *is* it? Before I put my data into a cipher file, I sure as hell want to know... What I find a bit peculiar: I have made an 8Mb test file in fs.img, and I overwrite a small part of it: (dd if=fs.img bs=1 count=1; dd if=/dev/urandom bs=1 count=8; dd if=fs.img bs=1 skip=10008) | fs2.img When I mount fs2.img, I get no error... what gives? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! #include signature.h signature.asc Description: Digital signature
Re: safety of encrypted filesystems
also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0915 +0200]: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. one dead block spills junk all over the block+1 when decrypted, but the (undamaged) encrypted block+1 is used to decrypt block+2 and so on. Ah, yeah, this makes perfect sense. I *knew* it even. I simply failed to see the big picture. So encrypted block devices are not really more dangerous than clear-text in the end... I suppose with AES you end up losing at least 64 bytes of data, which could be less without encryption... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! always remember you're unique, just like everyone else. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:36:07 +0200, Michael Buchholz writes: On Fri, 17 Jun 2005 17:15:32 +1000 Alexander Zangerl [EMAIL PROTECTED] wrote: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. That's a possible, but unsecure way to do that. please note that i was talking about encryption algo blocks, not filesystem blocks. what i've outlined is just the normal way cbc is implemented - which is what martin asked about. how far you chain is up to the implementer of a crypto fs; and of course there are pros and cons for chaining globally vs. chaining just a few crypto blocks into a single fs block. regards az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpHFH4Et7vjO.pgp Description: PGP signature
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? It is therefore better to use counter mode for clusters. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, Jun 17, 2005 at 09:03:57AM +0200, martin f krafft wrote: also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? wouldn't it be possible to test that? Scenario: encrypt /dev/hda7, mount, fill it with some hundred small files (with known content), unmount, change one bit/byte/block on /dev/hda7 (using dd), remount, look for the remaining files and their contents. I can imagine this might work; errors dont' have to be implemented in hardware, do they? Greetings Horst -- ... I don't know why but, suddenly, I want to discuss declining I.Q. LEVELS with a blue ribbon SENATE SUB-COMMITTEE! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: So encrypted block devices are not really more dangerous than clear-text in the end... I suppose with AES you end up losing at least 64 bytes of data, which could be less without encryption... You lose much more with RAID-5, yes. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Horst Pflugstaedt [EMAIL PROTECTED] [2005.06.17.1018 +0200]: encrypt /dev/hda7, mount, fill it with some hundred small files (with known content), unmount, change one bit/byte/block on /dev/hda7 (using dd), remount, look for the remaining files and their contents. I've tried that and the filesystem mounts without error. I have not yet figured out where the corruption occurs. It's an 8M filesystem (twofish) and I put an 8M file of all zeroes in there. After unmounting and deleting the loop device, I overwrote four bytes in the file with . Saving, setting up the loop devices, mounting... no errors. **And the file is still all zeroes...** So I guess there is error correction happening? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! work consists of whatever a body is obliged to do. play consists of whatever a body is not obliged to do. -- mark twain signature.asc Description: Digital signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 12:01:02 +0200 martin f krafft [EMAIL PROTECTED] wrote: devices, mounting... no errors. **And the file is still all zeroes...** So I guess there is error correction happening? Is there something in the logfiles? Maybe the cryptoloop is a little verbose about errors... -- mit freundlichen Gruessen / with friendly regards Michael BuchholzPhone.: +49 231 4755513 Paschknappstr. 13 Mobil.: +49 171 3111861 44265 Dortmund, Germany Fax...: +49 231 4755514 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.1218 +0200]: Is there something in the logfiles? Maybe the cryptoloop is a little verbose about errors... Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! there's someone in my head but it's not me. -- pink floyd, the dark side of the moon, 1972 signature.asc Description: Digital signature
Re: safety of encrypted filesystems
fre, 17 06 2005 kl. 12:30 +0200, skrev martin f krafft: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? Right. Files are only sparse if you seek to somewhere in the file and start your writing there. The empty space reads as \0's, but just writing \0's won't give you a sparse file. -- Salu2, Sren. smime.p7s Description: S/MIME cryptographic signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 12:30:58 +0200 martin f krafft [EMAIL PROTECTED] wrote: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? Right. This file contains 2^23 0x00's. The other thing, mentioned, will happen with this code: fd = open (empty_file, O_WRONLY, 0666); lseek (fd, 2^23, SEEK_SET); write (fd, ?, 1); close (fd); ls -l will show 8 MB du -a will show 1k Maybe, you'll like to try bigger damages to the encrypted fs, until the error correction breaks. And maybe, fill the file in the fs from /dev/randon instead of /dev/zero. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.1242 +0200]: fd = open (empty_file, O_WRONLY, 0666); lseek (fd, 2^23, SEEK_SET); write (fd, ?, 1); close (fd); dd if=/dev/zero of=file bs=1 count=1 seek=8388607 -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! durch frauen werden die hhepunkte des lebens bereichert und die tiefpunkte vermehrt. - friedrich nietzsche signature.asc Description: Digital signature
CAN-2005-1266 - Spamassassin
Hi there! Since the end of april there is known an security issue for Spamassassin, which is described here[0] This issue has been assigned CVE id CAN-2005-1266 [1]. The question which comes in my mind ... how (and when) will this be fixed in sarge, when the security infrastructure is broken. With kind Regards, Jan. [0] http://marc.theaimsgroup.com/?l=spamassassin-announcem=111886630726077w=2 [1] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1266 -- ,,_ If wishes were wings, o )~ would fly. -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a-- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M-- V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgpUKiy1YI2qg.pgp Description: PGP signature
Re: Security Support by the Security-Team
Greetings, Am Freitag, 17. Juni 2005 10:58 schrieb Florian Weimer: Rumors suggest that the technical foundations of security support for sarge and woody are working again. Nice to hear - however, a SpamAssassin-patch has to be ported to sarge.[1] Let's see... the Sec-Announce was posted ~2 days ago. I expect exploits to appear soon, considering the uhm, eh... commercial interest in delivering spam. Everyone is to invited, to count the number of days... Keep smiling yanosz [1] http://marc.theaimsgroup.com/?l=spamassassin-announcem=111886630726077w=2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
root login denied. But by what?
Hi, Logcheck has just given me three of the following: Jun 17 17:17:15 hexstream [877]: root login denied [username: (0), IP/port: no ip?!] Each one with a different PID. They appear in my /var/log/auth.log I've never seen this type of message before but I've recently upgraded to the latest release of stable. Does anyone know what generated the above log entries? And why is there no ip? Regards, David. -- .''`. David Ramsden [EMAIL PROTECTED] : :' :http://david.hexstream.co.uk/ `. `'` PGP key ID: 507B379B on wwwkeys.pgp.net `- Debian - when my girlfriend's away and there's nothing better to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
martin f krafft [EMAIL PROTECTED] writes: However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? Yes and no. If you change the first block in a set of CBC-chained blocks, the last block will change. But to recover the contents of the last block, you only need the last block and the preceding block (and the key). -- I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility. --Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root login denied. But by what?
On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote: Does anyone know what generated the above log entries? try: find /usr/sbin /sbin /usr/local/sbin \ /usr/bin /usr/local/bin /bin /usr/lib /lib -type f | \ while read f; do if strings $f | egrep -q 'no ip\?!'; then echo it's $f ! fi done And why is there no ip? I guess this is a bug.. Marcin -- Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root login denied. But by what?
On Fri, Jun 17, 2005 at 10:47:49PM +0200, Marcin Owsiany wrote: On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote: Does anyone know what generated the above log entries? try: find /usr/sbin /sbin /usr/local/sbin \ /usr/bin /usr/local/bin /bin /usr/lib /lib -type f | \ while read f; do if strings $f | egrep -q 'no ip\?!'; then echo it's $f ! fi done Thanks for that Marcin. Worked well and found the program that caused this. It was scponly. I'm guessing a shell user ran it from an SSH session and it's generated the log entries. So nothing to worry about! Thanks once again! David. -- .''`. David Ramsden [EMAIL PROTECTED] : :' :http://david.hexstream.co.uk/ `. `'` PGP key ID: 507B379B on wwwkeys.pgp.net `- Debian - when my girlfriend's away and there's nothing better to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with have you unmounted the file before writing to it? perhaps you changes was overwritten with the blok from cache -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
