Crispin Cowan wrote:
>Conversely, if someone presented me with a mechanism that promises that
>file descriptors don't leak across processes, I'd have a VERY hard time
>convincing myself that it was correct.
Well, I certainly agree that this is not easy!, but let me
give it a go, just for fun.
Claim: The only way to install a new file descriptor into a
process in a 2.2.14 kernel is via open(), fork() [and relatives:
clone(), vfork()], dup() [and relatives: dup2(), fcntl(,F_DUPFD)],
recvmsg(), exec(), and two other places that I think are kernel
bugs [*].
Analysis: These can all be mediated, and in fact Janus does
mediate all of them. (Yup, we knew about fcntl(F_DUPFD) and
have had protection in place against exploiting this for years.)
Only fork() et. al and recvmsg() permit passing of fd's across
processes.
Justification of the claim: Run
find /usr/src/linux-2.2.14 | xargs egrep \
'([>.]files)|fd_install|expand_files|fl_owner|get_unused_fd|\
do_fork|scm_detach_fds|scm_recv|open_dentry|do_pipe'
We hope this will find all places in the code that modify the
'files->fd' field of a task_struct. (We have to assume there is
no wacky aliasing: For instance, I assume noone accesses this field
as '*(((unsigned int*)current)+20)', or else all bets are off.)
Then one can verify that the above are the only places that affect
this field of any task_struct. This is a weaker justification
than I'd like, but it's not too bad, as assurance arguments for
legacy code go.
[*] The other places that I think are bugs:
- ioctl(fd,UIOCATTACHSEMA) acts like dup(fd) if fd was opened on
"/dev/usemaclone" [see usema(7m)]
- SMBFS calls _recvfrom(), which looks mighty fishy
I think they are bugs in the kernel, because many user-land
applications assume the invariant the following invariant: if
they don't call open(), the next-unused fd won't change.
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Apr 21 2001 - 18:18:55 PDT