Linux-kernel mailing list archive 1999-25,: Re: RFC: BSD system call revoke?

# Re: RFC: BSD system call revoke?

Chris Evans (chris@ferret.lmh.ox.ac.uk)
Wed, 23 Jun 1999 23:50:24 +0100 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Don Fisher: "compile error on pre 2.3.9"
- Previous message: Matthew Kirkwood: "Re: RFC: BSD system call revoke?"

Hi,

A sample revoke() implementation was already written, by (primarily)
Matthew Kirkwood, with minor assistance from myself. All voiced objections
were eventually fixed, but it never made it into the kernel..

Anyway, onto security issues plus misc. issues with your implementation.

1) It is not sufficient to just close the file descriptor. Some
potentially sensitive devices (and all files) may by mmap()'ed into
virtual memory. I think the solution was vmtruncate()

2) The impact of allowing arbitrary users to call revoke() on files they
own is unassessed, making it very very dangerous. root-owned processes
often deal with users' files, and may not be prepared to deal with a file
descriptor disappearing from under them. Hence I suggest limiting this
call to block devices/char devices.

2b) Worse, you trawl the entire process table. Fro each process, it's file
list is trawled. Allowing users access to do this would enable an
effective DoS (the kernel lock is held)

3) The revoke() definition mandates that close() on a revoked file
descriptor succeeds. By initial inspection, your implementation would
appear to return -EBADF

4) Similarly, it is mandated that read() to a revoked file descriptor
return 0 (not -EBADF)

5) The performance concern may be significant even if only root is calling
revoke(), and only then on user logins. In RH6.0 the console user is given
access to maybe 5-10 devices - that's 5-10 revoke() calls per login.

I'd love to see revoke() in the kernel, though. Most of the above issues
are pretty trivial to fix.

The revoke() patch is small, which suggests that if we get a serious
kernel guru to help us (hint hint Alan the security bod), we could be
looking at revoke() in kernel 2.4 with little effort.

As you have said, revoke() is a very useful security tool. RedHat6.0
out-of-the-box suffers from the lack of it.

Cheers
Chris

-
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.tux.org/lkml/

- Next message: Don Fisher: "compile error on pre 2.3.9"
- Previous message: Matthew Kirkwood: "Re: RFC: BSD system call revoke?"