Date: Fri, 21 Nov 2003 10:59:40 +0100 From: Pawel Jakub Dawidek <nick@garage.freebsd.pl> To: Wes Peters <wes@softweyr.com> Cc: Rayson Ho <raysonlogin@yahoo.com> Subject: Re: "secure" file flag? Message-ID: <20031121095939.GS511@garage.freebsd.pl> In-Reply-To: <200311201327.29226.wes@softweyr.com> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311201327.29226.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--4WCFFtl4AQpQKunj Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. +>=20 +> Better to overwrite it with a more "secure" pattern. See ports/=20 +> sysutils/obliterate for references. It has been mentioned before that= =20 +> this could be done on in the kernel, obliterating blocks in the VM=20 +> rather than zeroing them. I hadn't thought of applying at the file or= =20 +> filesystem level. +>=20 +> > 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?? +>=20 +> The closest we have is the 'rm -P' command and the above-mentioned=20 +> obliterate command. The overwrite pattern used in 'rm -P' is not=20 +> likely to be effective against a dedicated inspection of the disk; the= =20 +> one in obliterate somewhat more so. +>=20 +> This sounds like an interesting file flag. Would you expect the process= =20 +> to block on the unlink(2) call while the overwrite takes place, or for= =20 +> this to happen in a kernel thread? The former seems pretty straight-=20 +> forward, hacking at ffs_blkfree. The latter I really wouldn't know how= =20 +> 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. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --4WCFFtl4AQpQKunj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP73iCz/PhmMH/Mf1AQFlzwP+OU4obkTdCHcCKGL+fEWQPai8pnWZENI6 IGR274IL68GRwQRwcb4d3nTF1hUa4WhRRR+75SzWvMNwZ6zYDaRkDBK7Fz9Jn+qF fhAf6HpTWcBVvyZL3CAszHtRMkASu2y7BVhgEgIRD6vXGAfo30lR2DmKRQP1Wvck 7Kwq5l0xswE= =YyW8 -----END PGP SIGNATURE----- --4WCFFtl4AQpQKunj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031121095939.GS511>