On Fri, 16 Jun 2000, Jesse Pollard wrote:
> On Fri, 16 Jun 2000, you wrote:
> >Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
> >> Elfcap is insecure, and permits the generation of trojan horses.
> >
> >You keep on asserting that, but never bother to justify it beyond handwaving.
> >Security is relative. Is elfcap more or less secure than normal setuid-root?
> >(I would say clearly more secure, but I can't claim infallibility)
> Less secure - The reason I think so:
> 1. Given elfcaps are stored in the header of an executable.
> 2. some executables cannot be read
> 3. That means I cannot see what privileges are granted if I run the
^^^^^^^^^
For the last time elfcap *grants* NOTHING! It *revokes* *removes*
*disables*.
> executable, even if I'm just a user.
> With the capability list in the inode, I can just list the inode
> contents and see what privileges it has.
> Granted the setuid bit disables the elfcap, unless run as root....
> The problem still occurs if root is not allowed to read the executable
> for some reason. Suddently the executable has privileges I do not want
> it to have, nor to give it.
Wrong elfcap doesn't raise privledges. If you gave it nothing it has
nothing. Please correct your flawed understanding of elfcap effect on
privledges. Further more running a binary that is not in a location that
is not trusted with privledges is not smart no matter what. Hell if you
don't trust the location or can't audit the code I think you should look
into subterfuge or some other sandbox solution.
> It also means that the kernel is being tied to one executable format
> too. If something "better" than ELF format comes along then suddently
> it has to do the "capset" thing, which may not be the best for the format.
> I have found that separation of duty provides better overall security.
> ELF is designed to provide a program load capability. It isn't designed
> for security.
Being ELF specific is a potential drawback. I'd like to see a bincap
system if possible. Right now ELF and a.out are the only final binary
images. scripting languages also need to have some cap smartness built
into them. I think that bash, tcsh, python, perl are all good candidates
for extensions.
> I am a bit paranoid (the systems I try to protect are high target items).
Paranoia is good to a point. Being paranoid of something that can only
remove privledges when there are more interesting things someone with
write permisions on something you are running is not.
Simply not running something that someone you do not trust have write
permisions on it is even better.
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:13 EST