Re: Problem with the privileges of the KEXT package...
Re: Problem with the privileges of the KEXT package...
- Subject: Re: Problem with the privileges of the KEXT package...
- From: Dean Reece <email@hidden>
- Date: Wed, 29 May 2002 09:05:45 -0700
On Wednesday, May 29, 2002, at 03:55 AM, Stiphane Sudre wrote:
On Wednesday, May 29, 2002, at 09:17 AM, Kevin Van Vechten wrote:
Moreover than making the KEXT inaccessible to the group, it probably
should not be in /Library/, since that is (and should be) group
writable, limiting the effectiveness of any permissions to the KEXT.
A purist such as myself would contend that KEXTs belong in
/System/Library/Extensions, owned by root:wheel.
The KEXT system was designed to load KEXTs from anywhere as long as
their ownership & permissions were acceptable. Having a StartupItem
load them directly from within its own bundle is reasonable use of the
mechanism. We also envisioned applications that contain KEXTs which
only need to be considered while the app is running (e.g., a special
network sniffer tool).
On Tuesday, May 28, 2002, at 08:37 PM, Dean Reece wrote:
Right; the "standard" permissions we recommend are 644 for files and
755 for dirs. The owner/group should be root/wheel.
Minimally, your kext (all files & dirs) must be owned by root and may
not be writable by any user other than root. Obviously, to be read by
the kext loading system they need to be readable by root, but should
also be readable by non-root users in order for Finder and
AppleSystemProfiler to be able to present them in the GUI.
Thanks for all the answers, I tested with just removing the write
permission to the files and folders and it's now working. Cool.
Yet I must confess I have some problems with this scheme.
1) I don't like putting 3rd party kext (mine or others) in
/System/Library/Extensions:
The original decision to only scan /S/L/E by default is still the
current implementation. For future releases we may considered scanning
other places, but no plans have been made to do so.
2) I do agree with the fact that owner/group must be root/wheel for
items inside /System but I do not agree that it should be the case when
they are in /Library.
The ownership requirement is necessary regardless of location for
security reasons. A KEXT contains a binary that is loaded into the
kernel and executed. If that binary can be written by non-admin users,
then it can become a vehicle for all sorts of nasty attacks. For the
purposes of security, a KEXT must be thought of as a setuid binary and
treated as such.
* Since the owner/group of /Library is root/admin, this would be
incoherent.
* The kextload tool does not care at all whether the files are
root/wheel or root/admin. It just works with root/admin.
Right - The recommended ownership is root/wheel, but since group
writability is not allowed the actual group ownership can be anything
you prefer.
3) I don't see the interest to deny group write permissions to a kext
associated to a StartupItem.
* Denying write permissions prevent the file to be deleted from the
Finder. See point above about the Apple Installer.
Both the installation and removal of a KEXT requires authentication.
* Denying write group permissions protects almost nothing:
- Prevent the deletion of the kext: not really (see above)
- Prevent files with inappropriate permissions to be launched at boot
time: Startup Items can be in /Library/ and their associated scripts or
binary can be rwxrwxr-x root/admin, and are launched at boot time.
- If it's there to prevent the End user from deleting the file, write
group permissions with root/admin is fine too.
With the current permissions giving write permission to the admin
group, what I'm experiencing is this:
- End User can't delete the items
- End User can't delete the /Library folder
- End User can't change the items
- Admin User can delete /Library
- Admin User can delete /System
- Admin User can delete the items (included from the Finder)
- Admin User can change the items
I'm trying to imagine a case where giving write permissions to the
admin group can lead to a security issue but since this is already the
case with StartupItems...
We started with a very conservative set of requirements for KEXT
security with the understanding that we could relax them a bit if
needed. Presently, we have no plans to relax them, though if we hear of
specific cases that needlessly hinder end users, we'll have a look. We
won't relax them to the point that we compromise security though.
Side note: is there any official Apple/Darwin document which lists the
recommended file permissions for the various standard locations?
Not that I'm aware of. A good rule of thumb is to duplicate the
ownership & permissions of other items installed by Apple Software into
the same location.
Cheers,
- Dean
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.