On Tue, 2007-04-17 at 15:16 -0400, Eric Paris wrote:
> On Tue, 2007-04-17 at 13:40 -0500, Trevor S Highland wrote:
> > I am trying to open /selinux/avc/cache_threshold for writing as root
> > with the staff_r role. The open succeeds. When I attempt to write to
> > the file, the write succeeds if I write the value that is currently in
> > the file. If I write any other value write returns EPERM. From my
> > understanding staff_r should not have write access
> > to /selinux/avc/cache_threshold. If this is the case, can anyone
> > explain why the open succeeds.
> >
> > Thank you,
> > Trevor
>
> Well the implementation sees this as 2 different operations. The open
> is taken care of entirely by standard VFS securty hooks. AKA does your
> shell (staff_r) have permission to open a system_u:object_r:security_t
> file with write. Apparently policy says that it does and I see no
> reason why that couldn't be 'fixed' thus solving your inquiry. Dan?
>
> The second operation is actually setting the new value, in that case the
> kernel code looks like:
>
> if (new_value != avc_cache_threshold) {
> ret = task_has_security(current, SECURITY__SETSECPARAM);
> if (ret)
> goto out_free;
> avc_cache_threshold = new_value;
> }
>
> I could buy into switching the task_has_security() hook and the new/old
> comparison so you don't have the inconsistancy if you don't make a
> change and always get an EPERM but if you want the open to fail that's
> not a kernel problem and is just a policy issue.
Odd, I already had a discussion about this issue with Camilo Campo and
Kris Wilson of IBM in March and explained it to them at the time. They
chose to send me private email about it rather than to the list.
Prohiting all writes to security_t by staff_t would prevent use of the
policy decision interfaces that are transactional in nature.
Setting of things like the enforcing flag, booleans, and cache threshold
are checked at write time, not open time.
--
Stephen Smalley
National Security Agency
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
