Re: Improving capabilities support: need your opinion

Matthew Kirkwood (weejock@ferret.lmh.ox.ac.uk)
Fri, 11 Jun 1999 15:15:20 +0100 (GMT)


On Fri, 11 Jun 1999, Pietro Iglio wrote:

> Using the current implementation, if a program is setuid root only
> because it needs to override some file permission problems, we give it
> CAP_DAC_OVERRIDE instead of giving it ALL roots capabilities
> (eventually, only for a short period of time).

> PROPOSED SOLUTION: to enforce least privilege explicitly specifying
> files for which the standard access control should be overriden, along
> with the required access mask.

I wouldn't do that. There are ACL patches out there, which seem
to be stabilising quite nicely.

> #> chmod u+s myapp
> #> setcap -u nobody -c FILE_ACCESS:/etc/myapp.conf:w myapp

# addgroup myapp
# chacl myapp:g+w /etc/myapp.conf # I haven't used the ACL tools so
# don't know the right syntax
# chgrp myapp `which myapp`
# chown g+s `which myapp`

> IMPLEMENTATION DETAILS:
>
> The list of files corresponding to the CAP_FILE_ACCESS (new)
> capability is stored in the elf header. When myapp is executed, the
> kernel associates a list of entries (inode_number, rdev, mask) to the
> corresponding process. For this reason, I have extended task_struct.
> (inode_number, rdev) are used to identify the file and are determined
> using the paths stored in the elf header.

I'd avoid that, since inodes get reused. An attacker can start up
a priveleged binary, and suspend it until /etc/shadow gets the old
inode, and which point the app can start writing to the shadow file.

Better to store file permissions in files.

Matthew.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/