Jonathan
On Fri, 9 Apr 1999, Daniel Taylor wrote:
>
>
> On Fri, 9 Apr 1999, Albert D. Cahalan wrote:
>
> >
> > Dan Taylor writes:
> >
> > > We need to have per-user capabilities, "root" would be the
> > > ability to set these capabilities.
> >
> > No problem. We can have:
> >
> > Per-user capabilities for logins. (easy)
> Not for logins, simply per-user capabilities.
> Either you can do something or you cannot.
> If you do not have the capability to do something
> you need a program that is SUID to a user who can
> in order to do it.
>
> > Per-file capabilities for use by root. (easy)
> > Per-file capabilities for everyone. (hard, and for ext2 only)
>
> These can be implemented in filesystem or in executable.
> Or both.
>
> >
> > It is no problem to have 1, 2, or all 3 of the above.
> > They do not conflict.
>
> Except that with a proper capabilities model they are all the same thing.
>
> >
> > > But all of the filesystem or executable capability code in the
> > > world means _NOTHING_ if root is the only user with capabilities
> > > beyond what an ordinary user has now, since any executable with
> > > expanded capabilities must then be SUID root.
> >
> > So you hack PAM to add capabilities at login.
> >
> > You can make the capability setting tool have capabilities itself,
> > so that a normal user (with a few capabilities) could produce an
> > executable with additional capabilities. In doing so, they lose
> > write access to the file and the ELF header is mangled. Like this:
> >
> Do you have ANY idea the security issues this raises?
>
> > 1. owner becomes root
> > 2. capabilities added, as permitted for this user
> > 3. ELF header mangled to stop Linux 2.2 from doing setuid-root
> > 4. write permission removed
> > 5. the operation gets logged
> > 6. the setuid bit gets set
> >
> > The former owner can no longer edit the file. They can move it and
> > delete it, unless the immutable bit is set too. When the former owner
> > wants to edit the file, they can use the same tool to restore the
> > original non-root non-setuid properties.
> >
> It REALLY misses the point of using capabilities to provide
> security. There should be capabilities for new file creation,
> filesystem write and other things that need to be applied
> on a per-user basis.
>
> The executable inherits the capabilities of the user running
> it "anded" with its own.
>
> Daniel Taylor
>
>
> -
> 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/
>
-
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/