Re: Secure deletion

Richard B. Johnson (root@chaos.analogic.com)
Fri, 24 Jul 1998 08:53:19 -0400 (EDT)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---1295196120-766220837-901284799=:791
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 23 Jul 1998, Jeffrey B. Siegal wrote:

> Richard B. Johnson wrote:
>
> > Suppose you modified the 'C' runtime library so it could be recompiled with
> > a switch that changes anything that 'removes' files to:
> >
> > stat the file (to get length);
> > write the file with junk.
> > close the file.
> > sync the file-system.
> > unlink the file.
> > sync the file-system.
> >
>
> For one thing, it isn't atomic. If the length of the file increases after the
> stat, the extra blocks won't be cleared. This could be detected by adding another
> stat after the clearing (and a loop if necessary), but the length of the file could
> temporarily increase, and then decrease. Only the kernel can do this atomically.
>
> > The problem with doing this in the kernel is that any time anything
> > removes a file, you have to flush buffers to disk to make sure that
> > the new data gets to the physical media. This will slow the file-system
> > to a crawl.
>
> Remember, not every application is particularly performance sensitive. I'd be
> willing to accept poor performance for increased security *for certain
> applications*.

As others have mentioned 'security' comes in many flavors. If you want
to reduce the possibility of having someone read something that they
should not, to something very small, just fill up your disk(s) every
night with a file that contains junk, sync the file-system, then delete
the file.

If you have users who run programs in loops, trying to read something
they don't "own", then you need atomic, in kernel, stuff to prevent this.
The easiest way to prevent this is to use a properly-loaded '357, although
the may be frowned upon in some circles.

FYI, here is a program I use. It runs every night on my most-abused
file-server that has 40 interactive users, all hackers. Most have
PPP links from home through this system so they can try to do whatever
they try to do, without any chance of getting caught.

If you create a file with holes, or play other games to try to read
data you didn't create, your chances are not very great of reading
anything but "SECURITY ". Try it.

Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.108 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

---1295196120-766220837-901284799=:791
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="security.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.95.980724085319.791C@chaos.analogic.com>
Content-Description:

LyoNCiAqICBGcmVlIHNvZnR3YXJlIHRvIHdyaXRlIGEgc2VjdXJpdHkgcGF0
dGVybiBvdmVyIGRlbGV0ZWQgZmlsZS1zcGFjZQ0KICogIGluIHRoZSB3ZWUg
aG91cnMgb2YgdGhlIG5pZ2h0Lg0KICogIGNyb24gdXNhZ2U6DQogKiAgc2Vj
dXJpdHkgL2ZpbGVuYW1lDQogKiAgc2VjdXJpdHkgL2hvbWUvZmlsZW5hbWUN
CiAqICBzZWN1cml0eSAvdG1wL2ZpbGVuYW1lDQogKg0KICogIFRoaXMgd3Jp
dGVzIGEgZmlsZSBsYXJnZSBlbm91Z2ggdG8gZmlsbCB1cCB0aGUgZGlzayBw
YXJ0aXRpb24sDQogKiAgc3luY3MgdGhlIGZpbGUtc3lzdGVtLCB0aGVuIGRl
bGV0ZXMgdGhlIGZpbGUuDQogKiAgQ3JlYXRlZCAyMC1KVUwtMTk5OCByam9o
bnNvbkBhbmFsb2dpYy5jb20uDQogKiAgTm8gQ29weXJpZ2h0IGlzIGNsYWlt
ZWQgYW5kIHRoZXJlIGlzIG5vIHdhcnJhbnR5Lg0KICovDQoNCg0KI2luY2x1
ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8
c3RkbGliLmg+DQojaW5jbHVkZSA8ZmNudGwuaD4NCiNpbmNsdWRlIDxzdHJp
bmcuaD4NCiNpbmNsdWRlIDxlcnJuby5oPg0KI2RlZmluZSBCVUZfTEVOIDB4
MTAwMA0KI2RlZmluZSBGSUxFTkFNRSBhcmd2WzFdDQojZGVmaW5lIFdITyBh
cmd2WzBdDQojZGVmaW5lIExFTiAoc2l6ZW9mKHNlY3VyKSAtMSkNCg0KY29u
c3QgY2hhciBzZWN1cltdPSJTRUNVUklUWSAgICAgICAgIjsNCg0KaW50IG1h
aW4oaW50IGFyZ3MsIGNoYXIgKmFyZ3ZbXSkNCnsNCiAgICBpbnQgZmQsIGk7
DQogICAgY2hhciAqYnVmZmVyOw0KICAgIGNoYXIgKnA7DQoNCiAgICBpZihh
cmdzIDwgMikNCiAgICB7DQogICAgICAgIGZwcmludGYoc3RkZXJyLCAiVXNh
Z2U6XG4iKTsNCiAgICAgICAgZnByaW50ZihzdGRlcnIsICIlcyBwYXRobmFt
ZVxuIiwgYXJndlswXSk7DQogICAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsN
CiAgICB9DQogICAgaWYoKGZkID0gb3BlbihGSUxFTkFNRSwgT19SRFdSfE9f
Q1JFQVQsIDA2NDQpKSA8IDApDQogICAgew0KICAgICAgICBmcHJpbnRmKHN0
ZGVyciwgIkZyb20gJXMsIGZpbGUgY3JlYXRpb24gZXJyb3IgJXNcbiIsIFdI
TywNCiAgICAgICAgICAgICAgIHN0cmVycm9yKGVycm5vKSk7DQogICAgfQ0K
ICAgIGlmKChidWZmZXIgPSAoY2hhciAqKSBtYWxsb2MoQlVGX0xFTiAqc2l6
ZW9mKGNoYXIpKSkgPT0gTlVMTCkNCiAgICB7DQogICAgICAgICh2b2lkKWNs
b3NlKGZkKTsNCiAgICAgICAgKHZvaWQpdW5saW5rKEZJTEVOQU1FKTsNCiAg
ICAgICAgZnByaW50ZihzdGRlcnIsICJGcm9tICVzLCBjYW4ndCBhbGxvY2F0
ZSBtZW1vcnlcbiIsIFdITyk7DQogICAgICAgIGV4aXQoRVhJVF9GQUlMVVJF
KTsNCiAgICB9DQogICAgcCA9IGJ1ZmZlcjsNCiAgICBmb3IoaT0wOyBpPCBC
VUZfTEVOIC8gTEVOOyBpKyspDQogICAgew0KICAgICAgICBtZW1jcHkocCwg
c2VjdXIsIExFTik7DQogICAgICAgIHAgKz0gTEVOOw0KICAgIH0NCiAgICBm
b3IoOzspDQogICAgew0KICAgICAgICBpZih3cml0ZShmZCwgYnVmZmVyLCBC
VUZfTEVOKSAhPSBCVUZfTEVOKQ0KICAgICAgICAgICAgYnJlYWs7DQogICAg
fQ0KICAgICh2b2lkKWNsb3NlKGZkKTsNCiAgICAodm9pZClzeW5jKCk7DQog
ICAgZnJlZShidWZmZXIpOw0KICAgICh2b2lkKXNsZWVwKDEwKTsNCiAgICAo
dm9pZCl1bmxpbmsoRklMRU5BTUUpOw0KICAgIHJldHVybiBFWElUX1NVQ0NF
U1M7DQp9DQoNCg0K
---1295196120-766220837-901284799=:791--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html