lkml.org 
[lkml]   [1999]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: capabilities in elf headers, (my) final (and shortest) iteration
Hi David.

My thoughts...

> Many of you have brought up many valid arguments with respect to
> putting capabilities in the elf headers. This has caused my
> thinking to change over time, for instance I no longer think a
> capability-enabled binary should be marked setuid root. It was
> just too ugly.

> I think my current approach to this is quite close to true
> capabilities in the fs, if only for elf binaries. For each
> point in my specification, I'll compare and contrast my solution
> with real caps in the fs.

I can see a few possible problems with it...

> The good news is, this has gotten a bit shorter.

8-)

> Currently, the kernel makes no use of the 'sticky bit' on files
> (though it does on directories). I think an excellent use for
> this bit would be for marking elf executables as capability
> enabled. For this to work exactly as capabilities in the fs
> would, we have to modify kernel behavior a bit. From here on
> out I will refer to the 'sticky bit' as the 'cap flag'. The
> cap-elf headers should contain all three of the 128-bit
> capability sets; permitted, inheritable, and effective.

> The kernel needs to be modified with the following behavior:

> 1) The ability to set/unset the 'cap flag' requires the
> capability CAP_SETFCAP to be raised, defined in linux-privs this
> way: 'Allows the (re)setting of a files capabilities.' Note the
> same applies to creating a new file, such as unpacking a
> tarball. This behaves almost exactly like true caps in the fs.

Nodz...

> 2) When a process attempts to set the cap flag, the kernel must
> read the capelf headers and check them for validity, in exactly
> the same manner as if the user (process) were attempting to set
> those caps in the fs. In this respect, my scheme is exactly
> like true caps in the fs, except applying to elf binaries only.

In addition, the kernel should REFUSE to set the cap flag if the file
in question has either of the group-write or world-write attributes
set, of if the file does NOT have the owner-execute bit set. It should
also clear the owner-write attribute if that is set.

2A) When a process tries to modify the permissions of a file that has
the cap flag set, refuse to modify the permissions if the new
permissions have any write attribute set, or if they have the
owner-execute bit cleared, returning an error message indicating that
such settings are incompatible with capabilities.

2B) When a process tries to modify the owner or group of a file that
has the cap flag set, treat this as being an "unset cap flag, make
change, set cap flag" sequence of operations, and make NO changes
unless the entire sequence would complete successfully.

> 3) When a file has the 'cap flag' set, the kernel must treat it
> as immutable to prevent the owner from editing the capabilities
> directly in the binary. The user must first un-set the flag
> (checked exactly as if they were removing all caps in the fs),
> then modify caps, then attempt to re-set as in (2).

This can be done to the extent required by capabilities by
implementing rule 2A instead. Note that it should NOT be an error to
clear the group-execute or world-execute attributes of a capable
binary, since that only restricts who can run it and not what it can
do. In addition, 2B deals with the possibility of a limited capability
user cracking into a more capable user's account and using that
account to create a capable binary with them as owner.

> This differs significantly from true caps in the fs, although
> this sort of behavior might be advantageous in a caps system:
> consider a black hat who remotely logs in as some user; since
> the login is remote, likely no caps should be raised. But if
> that user owns a binary with a set of permitted caps, the black
> hat could modify the binary to do Evil Things (tm).

> Other than these three changes, I see no good reason why this
> wouldn't give us near-complete capabilities support _now_, with
> the ability to get rid of root and all. As a suggestion, 'root
> magic' in the kernel should also be a configurable option, so
> old, unmodified root behavior can be maintained during
> transition.

> OK, folks: lay it on me. thoughts, flames, what have you.

There's one possible security scare I can see with your proposal,
which is the following:

1. Use a cap-aware kernel to create an executable with enhanced
capabilities.

2. System gets rebooted to a cap-ignorant kernel for some reason.

3. Use tools under the cap-ignorant kernel to add other capabilities
to the said executable.

4. System later gets rebooted back to the cap-aware kernel.

5. User runs said executable, which now has modified behaviour and
capabilities.

Whilst that appears to be a difficult scenario to follow, it is most
definately a valid one to watch for, and I would suggest the following
addition to your prosal to help deal with it.

4) Include in the capabilities header a field holding the timestamp
of the last capabilities validation.

5) When a process tries to run a capable binary, check the validation
timestamp against the current kernel boot timestamp, and if they are
different (in either direction), perform a complete capabilities
validation on that binary, clearing the cap flag if it fails, and
setting the validation timestamp to the current kernel boot timestamp
only if it succeeds.

6) In addition, modify point 1 to also set the validation timestamp
to the current kernel boot timestamp if it successfully set the cap
flag.

Note that I haven't said to set the validation timestamp to the
current time when the successful validation is done since that leaves
the possibility of an attack where the attacker sets the validation
timestamp to some future time well after the next likely kernel
reboot. The method selected makes such an attack pointless.

One side effect of this method is that each capable binary will get
revalidated ONCE after each reboot, thus ensuring that any binaries
where capabilities are honoured has been reliably validated as such.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.243 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site