Messages in this thread | | | Date | Fri, 11 Jun 1999 15:15:20 +0100 (GMT) | From | Matthew Kirkwood <> | Subject | Re: Improving capabilities support: need your opinion |
| |
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/
| |