Re: Authoritative Hooks

sdsat_private

On Thu, 8 Nov 2001, Casey Schaufler wrote:

> An unprivileged process owned by stephen.nai ought to have
> write access to the file, based on the ACL. It will fail the
> mode bit check, however. Not to be denied, the capable() call
> will be made. The capable call will look in the security blob
> to determine what kind of object (file, SVIPC, socket, ...)
> being accessed so that it knows what kind of data to look for.
> It then looks for that data, in this case an ACL, and
> upon finding it, checks it against the process attributes. This
> will yield success, and the access will be granted.

Not exactly.  The capable call doesn't have any object information,
just the task and the particular capability.  I would expect you to
implement POSIX ACLs (or any other scheme that requires authoritative
behavior for file access controls) as follows:

1) The security module's capable hook function would always return
success for CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH.  This causes
a bypass of the kernel DAC logic in vfs_permission, ensuring that
the "restrictive" permission hook function is always called by the
kernel.

2) The security module's permission hook function would then perform the
complete (and authoritative) access control decision, including whatever
combination of POSIX ACLs and mode bit logic you want.

I believe that this is functionally equivalent to making the permission
hook authoritative.  In earlier discussions on this list, it was shown
that this capable+restrictive scheme doesn't work for all of the kernel
access controls (e.g. any case where CAP_SYS_ADMIN is used to override a
DAC decision, because it is also used authoritatively), but it appears to
work just fine in this case, and this appears to be sufficient for POSIX
ACLs.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module