On Thu, 14 Sep 2006, Alexander Leidinger wrote:

> Quoting Robert Watson (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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"