• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Blocking file access within KAUTH
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Blocking file access within KAUTH
      • From: "Damir Dezeljin" <email@hidden>
    • Re: Blocking file access within KAUTH
      • From: Michael Smith <email@hidden>
References: 
 >Blocking file access within KAUTH (From: "Damir Dezeljin" <email@hidden>)

  • Prev by Date: Re: Blocking file access within KAUTH
  • Next by Date: Re: Blocking file access within KAUTH
  • Previous by thread: Re: Blocking file access within KAUTH
  • Next by thread: Re: Blocking file access within KAUTH
  • Index(es):
    • Date
    • Thread