What new system calls do you want in BSD?

[John F. Haugh II]

In article <1990Feb9.025853.8202 at semi.harris-atd.com> del at 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 at rpp386.cactus.org