On Thu, 6 Oct 2005, David Howells wrote:
> > > Should I expand the permissions mask to include a setattr?
> >
> > Possibly for setperm and chown.
>
> For setperm?
It changes an attribute of a key, for which you have DAC checks, therefore
you could assume that we'd also want MAC checks.
> > > > All users of key_permission() need to propagate the error code from the
> > > > LSM back to the user.
> > >
> > > Really? Why?
> >
> > Because the LSM has final say on the error code returned to the caller.
> > If the LSM runs out of memory, for example, it's silly to return -EACCES.
> >
> > > Note that the fact that key_permission() fails for a key is sometimes
> > > ignored, such as when I'm doing a search and one potentially matching key
> > > fails, but a subsequent matching key passes.
> >
> > Ok, that sounds like an internal issue to be resolved, ensuring that if
> > you are returning to the caller, the LSM's error code is returned.
>
> But which LSM error code?
>
> Let me explain what I mean:
[snipped]
Thanks for the detailed explanation.
Not sure yet how we'll avoid generating spurious SELinux denial messages.
> Only if all these fail does the whole thing fail with the highest priority
> error. Note that several errors may have come from LSM.
>
> The error priority should be:
>
> EKEYREVOKED > EKEYEXPIRED > ENOKEY
>
> EACCES/EPERM should only really be returned on a direct keyring search where
> the basal keyring doesn't have Search permission.
Ok, if a failure of this nature is generated by an LSM, we need to return
the LSM's error code (e.g. ask the LSM for search permission and it
returns -ENOMEM).
> The fact that I couldn't find a key because I didn't have permission to find
> it probably shouldn't cause an immediate abort of the search with an error, or
> any error other than ENOKEY/EKEYREVOKED/EKEYEXPIRED, unless I'm not permitted
> to request a new key.
Ok.
- James
--
James Morris
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
