Re: "secure" file flag?
If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during "normal" operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? Actually, this is quite similar to what people at Vasco do (http://www.vasco.com). They make devices that (from what I can tell) hash a PIN and a timestamp (along with some other arbitrary values generated by a server, which are optional) and give you a return hash. From what I've seen, the hash is rather elementary and I feel somewhat silly using it to log into my bank. I sent an email to them a while ago; it seems that the security may lie somewhat on the knowledge of the hashing function. But there are definitely devices that do these sorts of things (although the ones from Vasco don't work with GSM, so sending the SMS back would have to go through the phone). Although, I must say, that sending the SMS via the phone is quite insecure as well. If you've the ability to send SMSes, you can most likely fake the address your SMS is coming from, just like you can fake an email. Although, AFAIK, it's a bit more difficult to track the origin of an SMS message. However, most new phones have J2ME capability. I hate Java, but since it's the HLL that we're allowed to use, we could make use of it. After Helix has had some time to be cryptanalyzed, it might be a good candidate for just this kind of application -- a lightweight, fast, easily implementable encryption and authentication algorithm (though it looks promising to me). Until then, some other kind of encryption/authentication could take place. In any case, many phones allow sockets to be created and sent (and if they don't, they most certainly support HTTPS channels). I think an app utilizing this would be a bit more secure in this scenario than one via SMS (or via the Vasco method, I don't have a ton of faith in their closed-source solution). This would be a good, mobile way to provide a one-time key, though. You might even be able to implement it to request keys from multiple administrators assuming the first administrator failed. Who knows. Haven't been following this discussing very closely, so feel free to poke me with a stick if I'm babbling about some obscure tangent. While you're in there, paint that bikeshed blue. Only if there's not someone painting it already :) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
In message <[EMAIL PROTECTED]>, Wilko Bulte writes: >On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote: >> I have already described one solution to this in my GBDE paper at >> BSDcon. > >... > >> Now *that* is a DIY project for the dedicated hobbyist :-) >> >> The terminology and principle, is from atomic weapons which have a >> similar security profile: >> http://nuclearweaponarchive.org/Usa/Weapons/Pal.html > >Your interests sometimes worry me... My interest in the cold war comes from having grown up in a place that had one of the highest ratios of nuclear bulls-eyes to human beings in Europe. "The Great Belt" is a deep (75m) narrow strait (20km) which would have been the soviets only chance of getting their baltic fleet out, the other two straits are small enough that they could be efficiently mined/blocked. Already then, we knew that both sides would have the strait in their atomic target lists, only later did we find out how very very certain they wanted to be. The trick is to be able to apply what you learn from one interest to productive uses in other interests. Poul-Henning PS: Interesting historical tidbit: The observation that missiles were on their way to Cuba came from the island Langeland in The Great Belt. If they hadn't noticed, the US blocade would have been too late and the world probably quite different. (http://www.rudkom.dk/museum/lm/frames/uk/menu/udstilling/fort01.html) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Wes Peters writes: > > >If you want an interesting problem to work on, come up with a solution to > >the keying problem for disk encryption. It somehow needs to allow > >automated, unattended reboots during "normal" operations but prevent > >attackers from compromising the system. Maybe you could have the system > >send an SMS message when it needs a key, you reply with a one-time key > >from your mobile phone? > > I have already described one solution to this in my GBDE paper at > BSDcon. ... > Now *that* is a DIY project for the dedicated hobbyist :-) > > The terminology and principle, is from atomic weapons which have a > similar security profile: > http://nuclearweaponarchive.org/Usa/Weapons/Pal.html Your interests sometimes worry me... ;-) -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
In message <[EMAIL PROTECTED]>, Wes Peters writes: >If you want an interesting problem to work on, come up with a solution to >the keying problem for disk encryption. It somehow needs to allow >automated, unattended reboots during "normal" operations but prevent >attackers from compromising the system. Maybe you could have the system >send an SMS message when it needs a key, you reply with a one-time key >from your mobile phone? I have already described one solution to this in my GBDE paper at BSDcon. You use weak-link/strong-link setups for that: Put the computer and a small UPS (5 minutes) in a good quality safe, drill a tiny hole in it, through which you run the power cord and a fiberoptic network connection. Put serious violation sensors *inside* the safe: corner integrity, door opening, tilt, humidity, mositure, temperature, pressure, gas, smoke, vibration. In addition put serious sensors on the network connection: packet filters, monitor the media state, wrong password attempts, significant changes in trafic level etc etc. As long as the violation sensors don't trigger (the weak link) the safe protects the keys (the strong link). If any of these sensors trip, if the safe is rocked, gets warmer, if the external power disappears, if the network connection looses connection, if somebody attempts to enter with a wrong sshd password, the computer *immediately* nukes its keys and other sensitive material and turns itself off, after which a breach of the strong link is no longer a risk to the data. Now *that* is a DIY project for the dedicated hobbyist :-) The terminology and principle, is from atomic weapons which have a similar security profile: http://nuclearweaponarchive.org/Usa/Weapons/Pal.html enjoy -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Monday 24 November 2003 10:24 pm, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Stefan > =?iso-8859-1 > > >And that is what this thread is about: Secure removal of data from > >storage media. There definitely is a difference between RLL (as in > >1,7i RLL) and modern PRML drives under this aspect. > > No there isn't. > > It's been proven again and again that you cannot reliably overwrite > data on a magnetic media. In particular the difference in read/write > geometry and lack of fine control over head placement makes this > impossible. > > The only reliable way to loose data is to encrypt them and throw the > key away. This is the conclusion I came to after pushing the idea around for months. If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during "normal" operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? While you're in there, paint that bikeshed blue. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
Wes Peters wrote: > On Tuesday 18 November 2003 16:31, Rayson Ho wrote: > > e.g. when deleting a "secure" file, the OS will overwrite the file > > with random data. > > Better to overwrite it with a more "secure" pattern. See ports/ > sysutils/obliterate for references. It has been mentioned before that > this could be done on in the kernel, obliterating blocks in the VM > rather than zeroing them. I hadn't thought of applying at the file or > filesystem level. The DOD has a specific pattern it requirs, to consider the deletion to be secure. > The closest we have is the 'rm -P' command and the above-mentioned > obliterate command. The overwrite pattern used in 'rm -P' is not > likely to be effective against a dedicated inspection of the disk; the > one in obliterate somewhat more so. On most modern drives, nothing is likly to be ffective, without OS support all th way down to the driver and hardware flags level. The DOD specified pattern is only effective if you have separate control of the seek and the write. The reason for this is that you musttake head hysteresis into account since if you did a seek in for the initial write and a seek out for the erase, you will ens up with a small strip of bits that are readable, even if they are much smaller than a standard track width, since there is jitter in the head positioning that depends on the side of the track you are coming from. So in reality, you also need to control sector sparing and write caching, as well, to avoid track caching, if possible, and seeks for sector sparing which are hidden from the OS trying to invoke the write pattern: you need to turn both of these off, if you can. If you can't, you need to buy a different disk, and turn both of these off, if you can. If you can't, you are going to ned to write your own disk firmware. You also need to deal with not writing to tracks at one end or the other of the disk, since you can't seek to them from the opposite direction, which means you have no way to write the pattern you are expected to write. This generally means that the end tracks need to be treated as "scrath landing zones", and you only ever write pattern data to them, and then only because that's the way to get the disk head onto the track so you can seek back to the track that you really want to erase. In a track-caching world, this tends to be not useful, unless you can determine the physical geometry of the disk, and treat tracks as separate entities. Finally, if you have a track-caching disk, it's likely that the way it operates is to just seek in and start writing. That will mean that in order to avoid a thin stripe of your old bits, you have to trat tracks as singl entities, and that means that if you have a track that shares data with several files, and you want to scribble over one of them effectively, you have to scribble over everything effectively, and then put the data for the filec(s) you didn't want to erase back on the track. > This sounds like an interesting file flag. Would you expect the process > to block on the unlink(2) call while the overwrite takes place, or for > this to happen in a kernel thread? The former seems pretty straight- > forward, hacking at ffs_blkfree. The latter I really wouldn't know how > to begin without (a lot) more study. You would have to do the former, or you would not pass common criteria valuation, if that's what you are aiming for. The normal way this is handled in government secure facilities is a 2U rack unit containing thermite charges. The normal way this is handled in a commercial scure facility is mostly to put the disks in a crusher. If this is somthing other than that, I doubt anyone would be willing to spend US$60,000/MB to have someone recover your porn. You are likely safe enough with PHK's somewhat inscure disk encryption thingy. As an overall note, you might want to contact Michal Serrachio off list; he has a solution to this problem which h might be willing to license to you for a fee. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
In message <[EMAIL PROTECTED]>, Stefan =?iso-8859-1 >And that is what this thread is about: Secure removal of data from >storage media. There definitely is a difference between RLL (as in >1,7i RLL) and modern PRML drives under this aspect. No there isn't. It's been proven again and again that you cannot reliably overwrite data on a magnetic media. In particular the difference in read/write geometry and lack of fine control over head placement makes this impossible. The only reliable way to loose data is to encrypt them and throw the key away. Live with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: > I am wondering if it is useful to have a "secure" file flag?? > > The secure file flag will be set for files that contain sensitive data. > Then the OS will take special care when operating on those "secure" > files. > > e.g. when deleting a "secure" file, the OS will overwrite the file with > random data. It would also be useful to have a "noexport" flag, which would have the NFS code refuse to send it over the network. I could personally use this for setting on my PGP and SSH keys, while exporting the rest of /home. I did look at implementing this, but couldn't find the "correct" place to do the check for the flag. Any pointers for a kernel newbie? Ceri -- pgp0.pgp Description: PGP signature
Re: "secure" file flag?
On 2003-11-24 12:20 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > Stefan Eßer <[EMAIL PROTECTED]> writes: > > Ok. I've also thought some about this, and I think that different media > > might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. > > Flash media). > > PRML is not an encoding scheme like MFM or RLL, it is an algorithm for > recovering a bitstream from a weak analog signal. Modern disks mostly > use RLL encoding. So what? PRML is not complementary to RLL. RLL is typically used to mean 1,7 RLL offering a 2/3 coding, while PRML starts at 8/9 and current devices use up to 24/25 (i.e. 24 bits in 25 channel bits). MFM can be considered a special case of RLL encoding, too, BTW ... But it's utterly irrelevant, that PRML data is written to disk as an RLL encoded data stream. What matters is what can be read back from the disk media (and PRML is about reading, not writing ;-) You probably don't want to claim that 1,7 RLL and a modern PRML encoding can be decoded with similar effort ... And that is what this thread is about: Secure removal of data from storage media. There definitely is a difference between RLL (as in 1,7i RLL) and modern PRML drives under this aspect. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
Stefan Eßer <[EMAIL PROTECTED]> writes: > Ok. I've also thought some about this, and I think that different media > might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. > Flash media). PRML is not an encoding scheme like MFM or RLL, it is an algorithm for recovering a bitstream from a weak analog signal. Modern disks mostly use RLL encoding. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-23 10:11 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > > Encrypting data and secure removal of data are orthogonal and in case > > you need one, the other propbably won't be a good choice. > > Both are completely adequate to protect the data on the disk from > disclosure. Yes, if effective. Encryption protects as long as the keys are unknown to the attacker, secure removal protects as long as the data is overwritten before the attacker tries to get access. I'm sure you know that ... > > fsck could identify incompletely erased (in the sense of multipass > > overwrite with specific patterns) blocks, if that state was marked in > > the inode. > > But if someone is attempting to recover your deleted data, they're not > going to run tools that would potentially eliminate that data from the > disk. I'm designing to the idea of a disk that has been physically taken > to a data recovery lab, because the intermediate steps don't interest me. > But you see that: Thanks! I'm getting more convinced that there might a chance to communicate, now ;-) > > This is not meant as protection in case power is removed and the disk > > is analyzed off-line since most probably no fsck will ever be run over > > the filesystem again. > > The data needs to be overwritten in a timely manner as well. Leaving the > disk in a partly erased state is the same as leaving it unerased. If you > don't want the processing delay needed to do the full erasure you > obviously don't really need full erasure. Yes. That's why encryption can be required. It protects data from the instant the clear-text has vanished (from RAM or some media). Secure deletion can't provide that! But there may still be situations, where you want to securely erase data from a medium. Either because that medium contained sensitive plain text or because it contained key data, for example (which is just another kind of sensitive plain text, in a way ;-) In that case, a small window of wulnerability may be tolerable (at least in a commercial environment). Encryption promises to keep existing data secret, and that promise may be broken. But in case you still need that data, you don't have much choice. Deleting it will not be an option. Secure erase gets rid of that data, and you don't have to worry that anybody may get hold of some kind of access key, once it's gone (which may take some time and effort to achieve, and that's what started this thread). Again: Nothing new to you ... > > It is meant to protect against a power failure (or reboot) with data > > not being erased according to the specification, which might survive > > for a long time after next start (not by an attacker but in normal > > service). This is extra paranoia (compare to a crash while "obliterate" > > is overwriting blocks, which will not be restarted after a crash ...) > > > > It seems that you are opposed to having "secure erase" support in the > > kernel, and in fact, I'm not sure it is that useful, myself. > > No, at one time I had it on my todo list, but came to a more full > understanding of the expense and abadoned it for that reason. I may > someday do it in the simplest form just to prove it workable to myself, > but I doubt that is a solution of general interest to FreeBSD. Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). High density disks (ATA more than SCSI, actually) seem to make it much harder to recover remains of overwritten data, and it may in fact be acceptable to perform just a few passes with random data (as suggested by Peter Gutmann, 7 years ago, when areal densities were one to two orders of magnitude lower than today ...) > > But in case it is considered useful and implemented (I'd try it myself, > > if I was interested in using this feature), then we should discuss the > > techical (and security) aspects of several designs and that's what I'm > > trying to do. > > There is some merit in providing a mechanism that is 90% as secure at 10% > the computational cost. I basic infrastructure that provides a "secure > removal" flag at the file and/or filesystem layer and a choice of > patterns would be a nice solution. Those who just want to make sure the > contents of an email aren't inadvertantly disclosed to another user could > specify a simple pattern like overwrite with zeros once, those who want > to keep the FBI at bay could use the whole 37 passes and spend days > deleting files. Maybe I'll look into this again after all. The former > variant seems like it might even be useful for a mail server or similar > application. The ability to specify different patterns seems useful. I'd consider a window of vulnerability of 10 seconds to one minute acceptable, and I guess this should be possible to acchive, even for nontrivial amounts of data that are to be deleted (40 passes at 1MB/s effective (including seeks) woul
Re: "secure" file flag?
In message <[EMAIL PROTECTED]>, Stefan =?iso-8859-1 ?Q?E=DFer?= writes: >Yes, probably. But encryption is only as good as key >management and secure storage (and deletion) of keys. >How do you implement unattended reboot, if you consider >unauthorized (physical) access to your system as one >of the attack scenarios to protect against ? >(Not meaning, that secure erase would really solve >that problem ...) See my paper for a suggestion about using weak-link/strong-link methods for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-23 18:04 +0100, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > 1. Look for BIO_DELETE in the kernel. Seems that BIO_DELETE isn't really supported anymore (according to a comment in your GEOM sources ;-) AFAICT, BIO_DELETE can't easily be made a long running operation (taking tens of revolutions of a disk media) without really hurting performance because of assumptions that it will take about the same time as BIO_WRITE ... > 2. Use GBDE or other encryption. Yes, probably. But encryption is only as good as key management and secure storage (and deletion) of keys. How do you implement unattended reboot, if you consider unauthorized (physical) access to your system as one of the attack scenarios to protect against ? (Not meaning, that secure erase would really solve that problem ...) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-23 17:31 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > Stefan Eßer <[EMAIL PROTECTED]> writes: > > What I'm suggesting is to have the obliteration implemented as an > > add on to the dirty buffer flush, with the difference that the > > buffer contents is prepared for the next step of the erasure process, > > written out, and then not declared free but again prepared for the > > next overwrite pass. > > This next pass won't be until thirty seconds later, so it'll take > about half an hour to completely obliterate a file. Furthermore, These 30 seconds are not a universal constant and ISTR. I had in mind, that one obliteration pass is performed. After each pass, a cache flush has to be performed, and the next pass is performed immediately or only after a brief delay. I see, that this may cause too many CPU cycles spent traversing the buffer cache. > unmounting a file system less than half an hour after a file is > deleted or truncated will fail, and shutting down will most likely > leave the file system unclean due to repeated failures to flush the > dirty buffer list. Yes, that's why I meant that fsck might be used to trigger the restart of an erasure process that was not completed due to shutdown or a crash. This does obviously no good in case that somebody else got hold of your disk, menawhile, but it covers cases that are not dealt with by a user-land utility (which would just be stopped halfway through when the system goes down). Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Sunday 23 November 2003 04:46 am, Stefan Eßer wrote: > On 2003-11-23 00:19 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > > On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: > > > On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > > > Stefan Eßer <[EMAIL PROTECTED]> writes: > > > > > I may be way off, but I do not think, that a special thread or > > > > > a cache flush after each block is required: [...] > > > > > > > > What happens if you yank the power cord? > > > > > > Worst case: The same thing that happened, if the you lost power > > > a fraction of a second earlier, just before the unlink or loss > > > of last reference to the file ... > > > > > > Nothing short of a self-destruct mechanism will do any better ;-) > > > > Poppycock. Encrypting the data before it hits the disk is a fine > > protection against somebody later recovering the data, either > > inadvertantly or nefariously. > > Aren't we again unneccessarily rude here ? > > Encrypting data and secure removal of data are orthogonal and in case > you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from disclosure. > In doubt, I'd use encyption at the disk block level to protect > sensitive data, but that's not the topic of this thread, IIRC. > > The subject was to get rid of remnants of data (whether encrypted or > not) from some magnetic media (and similar methods might be suitable > for flash media with different patterns and a smaller number of > passes). > > > Back to the subject of this thread: > > > You could write a special flag "needs to be securely removed" to > > > the inode. That way, an interrupted overwrite process could be > > > continued after next reboot (for example initiated by fsck). > > > > But why would somebody trying to steal your data run fsck on it? > > You're not thinking paranoid enough. > > Sorry, but what are you talking about ? > > fsck could identify incompletely erased (in the sense of multipass > overwrite with specific patterns) blocks, if that state was marked in > the inode. But if someone is attempting to recover your deleted data, they're not going to run tools that would potentially eliminate that data from the disk. I'm designing to the idea of a disk that has been physically taken to a data recovery lab, because the intermediate steps don't interest me. But you see that: > This is not meant as protection in case power is removed and the disk > is analyzed off-line since most probably no fsck will ever be run over > the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the disk in a partly erased state is the same as leaving it unerased. If you don't want the processing delay needed to do the full erasure you obviously don't really need full erasure. > It is meant to protect against a power failure (or reboot) with data > not being erased according to the specification, which might survive > for a long time after next start (not by an attacker but in normal > service). This is extra paranoia (compare to a crash while "obliterate" > is overwriting blocks, which will not be restarted after a crash ...) > > It seems that you are opposed to having "secure erase" support in the > kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full understanding of the expense and abadoned it for that reason. I may someday do it in the simplest form just to prove it workable to myself, but I doubt that is a solution of general interest to FreeBSD. > But in case it is considered useful and implemented (I'd try it myself, > if I was interested in using this feature), then we should discuss the > techical (and security) aspects of several designs and that's what I'm > trying to do. There is some merit in providing a mechanism that is 90% as secure at 10% the computational cost. I basic infrastructure that provides a "secure removal" flag at the file and/or filesystem layer and a choice of patterns would be a nice solution. Those who just want to make sure the contents of an email aren't inadvertantly disclosed to another user could specify a simple pattern like overwrite with zeros once, those who want to keep the FBI at bay could use the whole 37 passes and spend days deleting files. Maybe I'll look into this again after all. The former variant seems like it might even be useful for a mail server or similar application. Have you seen any literature on secure overwrite patterns for flash? That would be an interesting option to provide. If nothing else, I'd like to hack something like that into obliterate. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-h
Re: "secure" file flag?
On Sunday 23 November 2003 04:15 am, Stefan Eßer wrote: > On 2003-11-23 00:16 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > > On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: > > > A simple algorithm could just mark each buffer with a special > > > kind of dirty flag and a counter for the pass number (in fact, > > > the existing dirty flag could be used, and a counter set to the > > > number of passes required, with 0 indicating that the buffer is > > > to be flushed to disk "as is" in the normal way). > > > > Oh, but you're wrong, if you actually want to ERASE the data on the > > disk platters. That's why I've referred people to the obliterate > > program in ports several times. Read the references contained there, > > then come back to this discussion. > > This is rude! > > It's been some time since I read the Gutmann paper, but I still > remember the points he made and even quite a number of the details. > > Either my (English) language skills are insufficient to make my point, > or you just didn't read what I wrote. I thought it was obvious that > if I'm talking of several passes, that each one writes specific data > (either a complement of the original data, a suitable pattern or random > data). I'm sorry, I must've cut out the part where you wrote that it isn't necessary to flush the data through the drive cache. It is, because the patterns have to be applied in order and may not work if applied out of order. Therefore, you have to flush the data from the drives own cache onto the platters after you have applied each pattern. You can optimize this by moving the solution to a different layer or implementing a kernel thread, but the drive cache sync does need to be done. > What I'm suggesting is to have the obliteration implemented as an > add on to the dirty buffer flush, with the difference that the > buffer contents is prepared for the next step of the erasure process, > written out, and then not declared free but again prepared for the > next overwrite pass. A counter is required to keep the required > state information for each individual buffer. AFAIK, there is no > need to retain original data (or its complement) for the process, > so in fact all that is needed is a pass counter and the very simple > FA. There is no need for a special thread, and that was the point > I was trying to make. Yes, I see. For each block, you store the index of the next pattern to be written as each current pattern > Takling of obliterate: There is the patterns[] array and the "passno" > variable attached to a buffer could select one of those patterns on > each pass of the elevator. (Well, may be a seperate thread might be > better to prepare buffers by filling in the correct patterns at > slightly reduced priority ...) This would probably be an optimal solution. Given the difference between CPU performance and disk I/O speed, I've come to the conclusion disk encryption is probably a lower-cost solution. The big problem with disk encryption is the question "where do I get the keys from." -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
1. Look for BIO_DELETE in the kernel. 2. Use GBDE or other encryption. 3. Stop bikeshed now, please. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
Stefan Eßer <[EMAIL PROTECTED]> writes: > What I'm suggesting is to have the obliteration implemented as an > add on to the dirty buffer flush, with the difference that the > buffer contents is prepared for the next step of the erasure process, > written out, and then not declared free but again prepared for the > next overwrite pass. This next pass won't be until thirty seconds later, so it'll take about half an hour to completely obliterate a file. Furthermore, unmounting a file system less than half an hour after a file is deleted or truncated will fail, and shutting down will most likely leave the file system unclean due to repeated failures to flush the dirty buffer list. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-23 00:19 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: > > On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > > Stefan Eßer <[EMAIL PROTECTED]> writes: > > > > I may be way off, but I do not think, that a special thread or > > > > a cache flush after each block is required: [...] > > > > > > What happens if you yank the power cord? > > > > Worst case: The same thing that happened, if the you lost power > > a fraction of a second earlier, just before the unlink or loss > > of last reference to the file ... > > > > Nothing short of a self-destruct mechanism will do any better ;-) > > Poppycock. Encrypting the data before it hits the disk is a fine > protection against somebody later recovering the data, either > inadvertantly or nefariously. Aren't we again unneccessarily rude here ? Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. In doubt, I'd use encyption at the disk block level to protect sensitive data, but that's not the topic of this thread, IIRC. The subject was to get rid of remnants of data (whether encrypted or not) from some magnetic media (and similar methods might be suitable for flash media with different patterns and a smaller number of passes). > Back to the subject of this thread: > > > > You could write a special flag "needs to be securely removed" to > > the inode. That way, an interrupted overwrite process could be > > continued after next reboot (for example initiated by fsck). > > But why would somebody trying to steal your data run fsck on it? You're > not thinking paranoid enough. Sorry, but what are you talking about ? fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in the inode. This is not meant as protection in case power is removed and the disk is analyzed off-line since most probably no fsck will ever be run over the filesystem again. It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal service). This is extra paranoia (compare to a crash while "obliterate" is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having "secure erase" support in the kernel, and in fact, I'm not sure it is that useful, myself. But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-23 00:16 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: > > A simple algorithm could just mark each buffer with a special > > kind of dirty flag and a counter for the pass number (in fact, > > the existing dirty flag could be used, and a counter set to the > > number of passes required, with 0 indicating that the buffer is > > to be flushed to disk "as is" in the normal way). > > Oh, but you're wrong, if you actually want to ERASE the data on the disk > platters. That's why I've referred people to the obliterate program in > ports several times. Read the references contained there, then come back > to this discussion. This is rude! It's been some time since I read the Gutmann paper, but I still remember the points he made and even quite a number of the details. Either my (English) language skills are insufficient to make my point, or you just didn't read what I wrote. I thought it was obvious that if I'm talking of several passes, that each one writes specific data (either a complement of the original data, a suitable pattern or random data). What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. A counter is required to keep the required state information for each individual buffer. AFAIK, there is no need to retain original data (or its complement) for the process, so in fact all that is needed is a pass counter and the very simple FA. There is no need for a special thread, and that was the point I was trying to make. Takling of obliterate: There is the patterns[] array and the "passno" variable attached to a buffer could select one of those patterns on each pass of the elevator. (Well, may be a seperate thread might be better to prepare buffers by filling in the correct patterns at slightly reduced priority ...) > If you just want to zero the blocks, that is a lot easier, but you're not > really protecting anything from anyone who can get their hands on the > disk. Who is talking about just zeroing blocks ? Please take the time to actually read the messages you reply to ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: > On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > > Stefan Eßer <[EMAIL PROTECTED]> writes: > > > I may be way off, but I do not think, that a special thread or > > > a cache flush after each block is required: [...] > > > > What happens if you yank the power cord? > > Worst case: The same thing that happened, if the you lost power > a fraction of a second earlier, just before the unlink or loss > of last reference to the file ... > > Nothing short of a self-destruct mechanism will do any better ;-) Poppycock. Encrypting the data before it hits the disk is a fine protection against somebody later recovering the data, either inadvertantly or nefariously. > Back to the subject of this thread: > > You could write a special flag "needs to be securely removed" to > the inode. That way, an interrupted overwrite process could be > continued after next reboot (for example initiated by fsck). But why would somebody trying to steal your data run fsck on it? You're not thinking paranoid enough. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: > On 2003-11-21 14:09 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > > As for performance, you really need to flush the on-device cache on > > each pass to make sure the bit patterns get written to the platter in > > proper order. I don't see any clever way to coalesce the writing of > > the various patterns to multiple blocks short of a kernel thread, > > either, so performance would be abysmal. Imagine removing a large > > file, overwriting each block in 37 (IIRC) passes, syncing all the way > > through the on-disk cache after *every block.* > > I may be way off, but I do not think, that a special thread or > a cache flush after each block is required: > > A simple algorithm could just mark each buffer with a special > kind of dirty flag and a counter for the pass number (in fact, > the existing dirty flag could be used, and a counter set to the > number of passes required, with 0 indicating that the buffer is > to be flushed to disk "as is" in the normal way). Oh, but you're wrong, if you actually want to ERASE the data on the disk platters. That's why I've referred people to the obliterate program in ports several times. Read the references contained there, then come back to this discussion. If you just want to zero the blocks, that is a lot easier, but you're not really protecting anything from anyone who can get their hands on the disk. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: > Stefan Eßer <[EMAIL PROTECTED]> writes: > > I may be way off, but I do not think, that a special thread or > > a cache flush after each block is required: [...] > > What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) (You could provide an internal UPS and try to prevent unauthorized access to hardware components by sealing the components in a special enclosing, but I guess we are getting carried away. Better protect against unauthorized access to the computer and have it emergency shutdown (with secure deletion of critical information) in case of a (physical :) access violation. Back to the subject of this thread: You could write a special flag "needs to be securely removed" to the inode. That way, an interrupted overwrite process could be continued after next reboot (for example initiated by fsck). This is meant to protect against traces of sensible data being left on the disk for a long time after a crash. But such an inode would also indicate to an attacker the disk blocks that where considered needing protection and may make an attack at the magnetic residue practical at all ... But the real problem appears to be, when to mark the blocks and inode as free. Normally, the blocks are returned to the free block map when an inode is invalidated. File system blocks may not be reused, before the overwrite procedure has completed. Again, this requires that the inode is only removed after the last file block has been processed. But I'm not sure whether there is a mechanism that allows invalidating the inode after the last associated buffer has been flushed ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
Stefan Eßer <[EMAIL PROTECTED]> writes: > I may be way off, but I do not think, that a special thread or > a cache flush after each block is required: [...] What happens if you yank the power cord? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On 2003-11-21 14:09 -0800, Wes Peters <[EMAIL PROTECTED]> wrote: > As for performance, you really need to flush the on-device cache on each > pass to make sure the bit patterns get written to the platter in proper > order. I don't see any clever way to coalesce the writing of the > various patterns to multiple blocks short of a kernel thread, either, > so performance would be abysmal. Imagine removing a large file, > overwriting each block in 37 (IIRC) passes, syncing all the way through > the on-disk cache after *every block.* I may be way off, but I do not think, that a special thread or a cache flush after each block is required: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk "as is" in the normal way). All blocks belonging to the file must be read from disk, if not already present in some buffer, for the erasure process to start. (See below for large files.) In preparation of the first pass, the data in the buffer could be complemented and then written back to disk as in a normal dirty buffer flush. After some block has been written, its counter will be updated and the block will still be marked dirty, until the number of passes required to consider the data irrecoverable has been reached. (Blocks that had the counter set to 0 at the start of the flush are normal writes and need not be considered, here.) On successive passes, the block can be overwritten with specific bit patterns or random data according to some procedures for secure erasure of data from magnetic media. On each turn of the elavator algorithm, a cache flush is initiated, if the previous path included at least one buffer with the "secure erase" flag set. (Any number of unrelated reads or writes could have been executed during this path of the elevator.) After the specified number of iterations, the individual block will be marked as free and can be put into the free list. Until then, it can not be accessed or reclaimed. That way, the normal operation of the disk would not be impacted. On each pass of the elevator algorithm, each buffer flagged to be securely erased will be written once and its state will be updated. No special cleaner thread is required, just a byte for the counter. The biggest problem could be the first step of the algorithm (to read all file blocks into buffers that are marked dirty and get the number of the first erasure pass assigned). But I guess, that the erasure of long files could be broken in several parts, that each fit into the RAM available for buffers. Only this case would require that the unlink or process exit be delayed until the last part of the file has been read in and marked dirty and to be overwritten. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote: > Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes: > > I'm aware of this, but what we want to think over here is something > > like in-kernel 'rm -P'. So file will be overwriten even if it is > > opened and/or link count is grater than 0. > > That is not acceptable. First of all, it breaks a lot of assumptions > in the filesystem code. Second, it is incompatible with the common > technique of unlinking a temporary file immediately after opening it > to avoid having it stick around if the process that created it dies > prematurely. Your proposed change would thus reduce security rather > than enhance it. Right. The idea of restricting a file marked "secure" to not be able to link to it, and refusing to set the flag if the file has a link count greater than 1, is easy to do. I'm not sure it makes sense, though. > Besides, overwriting the contents of a file when it is removed from > the file system is not enough. You also need to overwrite every > block or fragment which is released any time the file shrinks. > > Fortunately, ufs always truncates a file to length 0 when it is > removed, so you only need to modify ffs_truncate() to implement both > aspects (truncation and removal). You should also take care to > overwrite the file's extended attributes if it has any. For ffs, I believe it would be as simple as providing this behavior in ffs_blkfree. Both the vnode and fs are passed to ffs_blkfree, so the code should be able to check filesystem flags and/or file flags to determine if the block should be erased before freed. This simplistic approach would forgo some potentially very helpful optimizations, though. > Finally, I think a filesystem flag is much better for this purpose > than a file flag; and in either case, file removal and truncation > performance will be awful. The filesystem flag is no more or less difficult to do; I can see doing both for completeness sake. As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* Disk encryption suddenly doesn't look so bad, does it? -- "Where am I, and what am I doing in this handbasket?" Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes: > I'm aware of this, but what we want to think over here is something like > in-kernel 'rm -P'. So file will be overwriten even if it is opened > and/or link count is grater than 0. That is not acceptable. First of all, it breaks a lot of assumptions in the filesystem code. Second, it is incompatible with the common technique of unlinking a temporary file immediately after opening it to avoid having it stick around if the process that created it dies prematurely. Your proposed change would thus reduce security rather than enhance it. Besides, overwriting the contents of a file when it is removed from the file system is not enough. You also need to overwrite every block or fragment which is released any time the file shrinks. Fortunately, ufs always truncates a file to length 0 when it is removed, so you only need to modify ffs_truncate() to implement both aspects (truncation and removal). You should also take care to overwrite the file's extended attributes if it has any. Finally, I think a filesystem flag is much better for this purpose than a file flag; and in either case, file removal and truncation performance will be awful. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Fri, Nov 21, 2003 at 12:41:05PM +0100, Dag-Erling Sm?rgrav wrote: +> > If this operation is able to fail (and of course it is) it should block +> > on unlink(2). +> +> FreeBSD is not DOS; unlink(2) does not actually remove the file. It +> is removed by the filesystem if the link count is zero when the vnode +> is released, which may be immediately after the unlink(2) call, or an +> indefinite amount of time later if the file was open at the time. I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That's why allowing link(2) operation for such files don't make much sens (the problem exists when there are hardlinks before "secure" flag is set). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: "secure" file flag?
Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes: > If this operation is able to fail (and of course it is) it should block > on unlink(2). FreeBSD is not DOS; unlink(2) does not actually remove the file. It is removed by the filesystem if the link count is zero when the vnode is released, which may be immediately after the unlink(2) call, or an indefinite amount of time later if the file was open at the time. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Fri, Nov 21, 2003 at 10:59:40AM +0100, Pawel Jakub Dawidek wrote: >Such "secure" flag for running process could be also implemented with >multiple meanings: Is the "secure" flag intended to protect the process image from the invoking user as well as other users? >1. All freed pages have to be zeroed. >2. All removed files have to be overwritten. >3. Umask for newly created files should be 0077. >4. "secure" flag for newly created files should be forced? >5. ... 5. Modified pages can't be written to swap (unless swap is encrypted). 6. Process get setuid-type treatment of core-dumps and rtld environment etc ... Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Thu, Nov 20, 2003 at 01:27:29PM -0800, Wes Peters wrote: +> On Tuesday 18 November 2003 16:31, Rayson Ho wrote: +> > I am wondering if it is useful to have a "secure" file flag?? +> > +> > The secure file flag will be set for files that contain sensitive +> > data. Then the OS will take special care when operating on those +> > "secure" files. +> > +> > e.g. when deleting a "secure" file, the OS will overwrite the file +> > with random data. +> +> Better to overwrite it with a more "secure" pattern. See ports/ +> sysutils/obliterate for references. It has been mentioned before that +> this could be done on in the kernel, obliterating blocks in the VM +> rather than zeroing them. I hadn't thought of applying at the file or +> filesystem level. +> +> > One advantage would be to have "secure" files in the same filesystem +> > as other normal files. +> > +> > Any one knows if FreeBSD has already implemented this?? +> +> The closest we have is the 'rm -P' command and the above-mentioned +> obliterate command. The overwrite pattern used in 'rm -P' is not +> likely to be effective against a dedicated inspection of the disk; the +> one in obliterate somewhat more so. +> +> This sounds like an interesting file flag. Would you expect the process +> to block on the unlink(2) call while the overwrite takes place, or for +> this to happen in a kernel thread? The former seems pretty straight- +> forward, hacking at ffs_blkfree. The latter I really wouldn't know how +> to begin without (a lot) more study. If this operation is able to fail (and of course it is) it should block on unlink(2). User has to be informed about status of operation like this one to give user a chance to do something else, performace isn't high-priority here, IMHO. Creating hard links to such file should be also forbiden (maybe only for non-owners). Another usefull thing will be posibility to pass flag to unlink(2) syscall to force "secure" removal (or "secure" removal in non-blocking mode as well). This will be more intuitive for programms that operate on many temporary files with sensitive data AND/OR allow setting this flag for directories. BTW. Poul-Henning Kamp proposed in his junior-kernel-hacker-todo-list mechanism that will provide zeroing all pages freed by 'special' process. This could be also implemented as file-flag (no modifications of source needed and this could be also used with close-source applications). Such "secure" flag for running process could be also implemented with multiple meanings: 1. All freed pages have to be zeroed. 2. All removed files have to be overwritten. 3. Umask for newly created files should be 0077. 4. "secure" flag for newly created files should be forced? 5. ... :) While phk is no more reading this list I'm CCing this mail to him. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: "secure" file flag?
On Tuesday 18 November 2003 16:31, Rayson Ho wrote: > I am wondering if it is useful to have a "secure" file flag?? > > The secure file flag will be set for files that contain sensitive > data. Then the OS will take special care when operating on those > "secure" files. > > e.g. when deleting a "secure" file, the OS will overwrite the file > with random data. Better to overwrite it with a more "secure" pattern. See ports/ sysutils/obliterate for references. It has been mentioned before that this could be done on in the kernel, obliterating blocks in the VM rather than zeroing them. I hadn't thought of applying at the file or filesystem level. > One advantage would be to have "secure" files in the same filesystem > as other normal files. > > Any one knows if FreeBSD has already implemented this?? The closest we have is the 'rm -P' command and the above-mentioned obliterate command. The overwrite pattern used in 'rm -P' is not likely to be effective against a dedicated inspection of the disk; the one in obliterate somewhat more so. This sounds like an interesting file flag. Would you expect the process to block on the unlink(2) call while the overwrite takes place, or for this to happen in a kernel thread? The former seems pretty straight- forward, hacking at ffs_blkfree. The latter I really wouldn't know how to begin without (a lot) more study. -- "Where am I, and what am I doing in this handbasket?" Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: > I am wondering if it is useful to have a "secure" file flag?? ... > e.g. when deleting a "secure" file, the OS will overwrite the file with > random data. I've got patches somewhere for zeroing out memory mappings in this way, but they are incomplete. :-( BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"secure" file flag?
I am wondering if it is useful to have a "secure" file flag?? The secure file flag will be set for files that contain sensitive data. Then the OS will take special care when operating on those "secure" files. e.g. when deleting a "secure" file, the OS will overwrite the file with random data. One advantage would be to have "secure" files in the same filesystem as other normal files. Any one knows if FreeBSD has already implemented this?? Thanks, Rayson __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
