Re: Blocking file access within KAUTH
Re: Blocking file access within KAUTH
- Subject: Re: Blocking file access within KAUTH
- From: Michael Smith <email@hidden>
- Date: Sat, 24 Nov 2007 20:23:18 -0800
On Nov 24, 2007, at 3:32 PM, Damir Dezeljin wrote:
So it seems I have to use the KAUTH_SCOPE_VNODE scope. However, as I
know, it is impossible to 'filter' only open operations (access) in
the VNODE scope. Am I right?
I'm not sure I understand what you are asking here (did you mean "as
far as I know"?).
Authorisation for file operations is computed at file open time by the
handlers in the KAUTH_SCOPE_VNODE; they are asked "do you want to
allow this". KAUTH_SCOPE_FILEOP handlers are told "this has already
happened".
We do not support revocation of granted authorisation for files, so
there is no interface on a per-operation basis (operations are
coalesced for a variety of reasons that would make revocation
difficult to implement, and applications would deal very badly with
revocation in general, so it is not a path that is worth pursuing).
Well, my concern is I want to minimize the kernel <-> user space
trafic and so I would like to request user-space processing only
once per file open lifetime (until the close() ).
If you mean that you only want your kernel<->user conversation to
happen when an attempt is made to open a file, then you can do this
fairly easily.
Please, can anyone give me a suggestion how to address this issue?
You want to register in KAUTH_SCOPE_FILEOP.
Without knowing what your policy is, I can't tell you how to decide
whether you should communicate with your user-space component or not.
Here are a few things to consider:
- You may have more than one right being requested at a given point
in time. Think carefully about whether you care about specific rights.
- Check what the vnode you're being passed is, consider
vode_isreg(), vnode_isdir(), etc. Think carefully about what will
happen when you are passed vnodes of any type (including types you
don't know or care about).
- Check the path to the vnode. Be prepared to deal with vnodes that
don't have paths you understand, or don't have paths at all.
- The KAUTH_VNODE_ACCESS bit tells you that the request is advisory
- there isn't an operation actually in progress, but someone wants to
know whether it would be permitted. You may want to ignore operations
with this bit set for performance reasons, but be aware that it may
give odd results.
- If you don't have an opinion on an operation, return
KAUTH_RESULT_DEFER. Do not return KAUTH_RESULT_ALLOW unless you have
a specific opinion. Note that the kernel default policy handler for
KAUTH_SCOPE_VNODE always has an opinion, and you cannot override it
when it decides to deny an operation.
Another thing I'm looking for is the posibility to attach some kind
of 'file context' to the file on open. This would help a lot as I
would be able to do the user-space processing on KAUTH_SCOPE_FILEOP
and attach results for all subsequential VNODE callbacks related to
the mentioned file. However; I guess this is not possible, but
please correct me if I'm wrong.
No, this is not possible. There are a number of things that the
kernel reserves the right to do with vnodes that would ruin most of
the assumptions that you might want to make about vnode pointers
passed to scope handlers. If you need to maintain persistent state
about open files on a per-process basis, I encourage you to consider
using library interposing and doing your work in user space entirely.
It may not be sufficient for your needs, but the guarantees associated
with open files there are somewhat more solid.
Additionally - is there any way how to avoid calling vn_getpath()
for every vnode callback (e.g. if it was already called for the
opened file)?
The namecache makes vn_getpath() quite cheap; don't worry too much
about it for KAUTH_SCOPE_VNODE.
Note that KAUTH_SCOPE_FILEOP handlers are more performance-sensitive,
and the scope handler is given a pointer to the path already.
Do not assume that the path to a file will remain the same over its
lifetime. Open files move, and you must be prepared to handle this
(you will be notified post-facto via KAUTH_FILEOP_RENAME).
And the last question for today -> I found two or three different
VNODE callback parameters explanations on the internet. Where can I
get the 'official' (the correct) one?
The definitive source of information is the source code; the system
registers a KAUTH_SCOPE_VNODE handler to implement the normal file
access checking. This is currently vnode_authorize_callback() in xnu/
bsd/vfs/vfs_subr.c
It takes the following arguments:
static int
vnode_authorize_callback(kauth_cred_t cred, void *idata,
kauth_action_t action,
uintptr_t arg0, uintptr_t arg1, uintptr_t
arg2, uintptr_t arg3)
{
vfs_context_t ctx;
vnode_t vp, dvp;
ctx = (vfs_context_t)arg0;
vp = (vnode_t)arg1;
dvp = (vnode_t)arg2;
ctx is the vfs_context_t for the operation. This is where you should
fetch the process and credential associated with the operation - do
not use current_proc() as the request may have come from another
task. Likewise, do not use the cred argument - fetch the credential
from the vfs_context_t.
vp is the vnode pointer for the object against which the operation is
being authorised.
dvp is the parent directory, for operations (specifically
KAUTH_VNODE_DELETE) where rights have to be considered vs. both
against the object and its parent. This is often NULL; if you need
the parent directory you should use vnode_getparent(). Note that
vnodes may have multiple parents; you should be prepared to be given a
parent vnode that is not the directory in which your client looked up
the file. Likewise there can be multiple paths to a node, so
vnode_getpath() may also give you unexpected results.
action is a bitmask of KAUTH_VNODE_* rights. For an operation to be
permitted, ALL of these rights must be granted.
HTH
Also, if you feel that the technotes could be improved on, please file
a bug with specific comments. Quinn and the DTS guys do a great job
of maintaining these, but they can always use your feedback.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden