Re: New in-kernel privilege API: priv(9)
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Thu, 14 Sep 2006 22:53:40 +0100 (BST)
On Thu, 14 Sep 2006, Alexander Leidinger wrote:
Quoting Robert Watson <rwatson@xxxxxxxxxxx> (from Wed, 13 Sep 2006 15:29:14 +0100 (BST)):
privilege list in src/sys/priv.h:
...
PRIV_UFS_SETQUOTA, /* setquota(). */
PRIV_UFS_SETUSE, /* setuse(). */
PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */
Is this something special to UFS, or did you use the UFS part only because no other filesystem in the tree has support for quotas?
They were labeled as UFS because they are currently somewhat UFS-specific, but you're right: it might well make sense to rename them to VFS as other file systems may gain support in the future. I'll make this change in P4.
It is my intent, following review, discussion, cleanup, etc, to commit the priv(9) work, sans mac_privs, to the 7.x tree in the next couple of weeks. The mac_privs policy is a sample policy that will continue to be maintained as part of the TrustedBSD Project, but not merged into the base tree at this point.
Is the mac_privs policy just a proof of concept? It would be nice to allow more fine grained access to some users or applications. The later one would need some way to identify the application/binary in a safe way, maybe by using extended attributes in the FS.
Yes, I consider it a proof of concept. Per my comments in a previous e-mail, I'm hesitant to rush into a modified privilege policy that either restricts the root user, or grants privileges to other processes, without a lot of careful thinking. The POSIX.1e-like privilege models used in many operating systems contain many subtleties, and in prior work on FreeBSD to experiment with those models, it was clear the level of risk in such a change was high. You can see some of this complexity by looking at the inheritence/etc logic in the linux POSIX.1e code, the Solaris privileges(5) man page, or the POSIX.1e draft specs. A lot of the complexity comes out of the binding of privileges to files (similar to setuid) and the details of the inheritence and compatibility support for "unaware" applications. If you take a glance at the trustedbsd_cap branch, you can find an implementation of POSIX.1e capabilities on FreeBSD from several years ago. I'm not opposed to revisiting this general issue, and in fact, the priv(9) work is intended to facilitate exactly that sort of work, but we need to do it very carefully.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- New in-kernel privilege API: priv(9)
- From: Robert Watson
- Re: New in-kernel privilege API: priv(9)
- From: Alexander Leidinger
- New in-kernel privilege API: priv(9)
- Prev by Date: Re: New in-kernel privilege API: priv(9)
- Next by Date: Re: New in-kernel privilege API: priv(9)
- Previous by thread: Re: New in-kernel privilege API: priv(9)
- Index(es):
Relevant Pages
|
|
