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: Sun, 25 Nov 2007 10:24:53 -0800
On Nov 25, 2007, at 12:30 AM, Damir Dezeljin wrote:
Anyway I'll try to clarify my use case a bit better:
Lets say I'm implementing a virus scanner and I want performing some
actions only when (before) the file data is being accessed. So,
ideally I would skip all directory listing or chmod-s, renames and
other operations not requiring file data. As I understood it is not
possible to distinguish between all such operations, but I have to
deal with VNODE action bit mask and do my decision depending on
results (well, first I have to check if the VNODE is a file ...). As
far as good -> I'm going to do some more testing and I guess I'll
return with additional questions later on.
You're not interested in operations, since you can't know what all the
operations are. You're interested in the rights being granted,
because they are set in stone.
BTW: I don't really care about the path I get from the VNODE. The
only important thing is I will be able to open the resolved path in
user space and scan the file. Depending on results, I'll block the
file access. I'm concerned about performance and results of my
approach for cases Michael described:
----
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 are scanning on open, then you can (and should) ignore the
advisory requests.
I some not directly related questions to the subject:
- I have just one MAC available right now. I'm using it for
developing and testing too. This makes it hard tracking down kernel
(my KEXT) deadlocks as I had to reset it lot of times already :)
I'm wondering if it is possible to debug the kernel remotely using a
Linux / Windows box?
Or is it possible to run Darwin on a normal PC (not MAC) - I'm
pretty sure it is, but I don't know if it is possible compiling or
just loading KEXT-s on such installations.
You will need another Mac. I'd recommend you consider a Mini - I use
a small farm of them for debugging/testing/etc. in conjunction with a
KVM; they are very economical in that regard.
Basically I bumped into two and a half issues :):
1. Hard links - path resolution
I'm considering implementing kind of exclude directory filtering in
kernel itself. I guess this would help lower the overhead until when
the 'filtering code' is small and fast as this will reduce kernel <-
> user communication by > 50%. The problem are hard links:
I created p1.src as a regular file in a directory I'm scanning (is
not excluded). Than I created two hard links to this file
(p2.src.hrd and p3.src.hrd) in the same directory. Afterwards I
moved the p2.src.hrd to an excluded directory. By doing this I was
not getting any notification for the other two hard links (well, the
original file and one hard link) that were still in a not-excluded
directory. So, suppose the excluded directory is /test/excluded.
Doing 'cat /test/excluded/p2.src.hrd' doesn't trigger a notification.
After some more investigation I found out the vnode_vfsname() always
resolves to the last modified hard link (or original file) instance.
I found such a behavior a bit bizarre; however, I'm sure there
should be a good reason for this (name resolving cache?).
vnode_vfsname() returns the name of the VFS (filesystem) that the
vnode is hosted on.
I assume you mean vnode_getpath(). Yes, the namecache will only give
you one of a set of possible paths to a node.
Think of the filesystem namespace as a database index. It is possible
to have multiple indices referencing the same record, and the
relationship between the record and the index entries is not reflexive.
Is there any way to workaround this problem -> so to get the actual
path of the file (hard link) that was accessed?
No. And as I noted previously, there are cases where this won't help
you anyway.
2. Denial hard link creation
Is there a way to prevent creation of hard links -> heh, this would
be a dirty work around for the first case :)
Yes, the act of linking to an object is authorised with
KAUTH_VNODE_LINKTARGET.
Note that blocking this indiscriminately will break many things and
you would still have the problem that a hardlink could be renamed into
your protected area; there is not a good way to determine that this is
being done.
(KAUTH_VNODE_ADD_FILE does not pass the vp for the file being added in
the rename case - it probably should so that this sort of thing could
be done).
3. File movements
This is my KEXT debug trace of a 'mv /test/p1.src /test/
p1.src.renamed':
----
DELETE on file '/test/p2.src.hdr'
READ_ATTRIBUTES READ_SECURITY on file '/test/p1.src.renamed'
READ_DATA on file '/test/p1.src.renamed'
READ_ATTRIBUTES READ_SECURITY on file '/test/p1.src.renamed'
READ_ATTRIBUTES on file '/test/p1.src.renamed'
READ_ATTRIBUTES on file '/test/p1.src.renamed'
READ_DATA on file '/test/p1.src.renamed'
----
I'm confused and concerned about "READ_DATA on file '/test/
p1.src.renamed'" outputs.
You probably have Spotlight running. Turn it off. It will confuse
you *greatly*.
= 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