Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: What new system calls do you want in BSD?
Message-ID: <17898@rpp386.cactus.org>
Date: 10 Feb 90 01:41:11 GMT
References: <12157@stealth.acf.nyu.edu> <1990Jan24.193433.3332@semi.harris-atd.com> <23449@stealth.acf.nyu.edu> <1990Feb8.080645.4458@semi.harris-atd.com> <5068.16:48:52@stealth.acf.nyu.edu> <1990Feb9.025853.8202@semi.harris-atd.com>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Distribution: usa
Organization: Lone Star Cafe and BBS Service
Lines: 37

In article <1990Feb9.025853.8202@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes:
>>> I don't want it to update the ctime either.
>>
>>That would be a security violation.
>In what way?  The only information that I lose is that I can't tell if
>someone has been looking at my files.  If I cared then I would make them
>something other than rw-r--r--. Even in the present scheme, if I read my
>file after the "cracker" has, then I can't tell if it was previously read.

In some sense of the word "secure" information about whether a particular
file has been referenced is "security relevant".

In the typical "insecure" UNIX environment it would be useful to be
able to read a file without updating the atime or ctime.  In that
sense an "O_PEEK" flag would be Real Nice(tm).  File backup utilities
are forced to use utimes() which as a side-effect changes the ctime,
not really a nice thing to do consider file backup utilities tend to
use the ctime for selecting files to dump ...

In a more secure environment it is possible to track references to
individual files with more granularity than "yes/no" and when.  A
feature like "O_PEEK" probably wouldn't matter in this case either
since interesting files are going to be tracked with other mechanisms.

Dan's assertion that O_PEEK is a "security violation" is only true
in the most simplistic sense.  It most certainly is not a "security
violation" in any "official" sense of the word.  This is borne out
by 2.2.2.2 of the TCSEC - the different times in the i-node DO NOT
provide the function required for conformance.  So I do not see how
any possible mis-use could be contrued to be a lack of protection.

Indeed, were such a feature to be provided the only requirement would
be that its use be restricted in some fashion and that use of this
feature be auditable.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org