Yes. I got as far as looking at elf.h, and noting that the header file
alone wouldn't tell me much about alignment, ordering, and other rules.
I believe there is an ELF developer document somewhere at metalab.unc.edu,
mixed in with gcc somewhere. (not in the LDP area)
For development purposes, a script using binutils stuff might be
the most practical. Like this:
1. create /tmp/plain, with any capabilities info removed
2. create /tmp/cap, containing the binary blob (or nulls if none)
3. run a simple tool to hack the capabilities info
4. merge the two parts back together
Eventually it would be nice to have a tool that uses capabilities
itself to provide enhanced executables for authorized users.
Results would be stripped of write permission of course, and the
operation could be logged.
> If you want this NOT to run on older kernels, turn "ELF" signature
> into "FLE". New kernel will recognize it, old will not -> executable
> will fail.
This is good. For future expansion, a kernel feature bitmap (like ext2 has)
or minimum version number might be good to have.
> PS: This should work, but I do not feel too well having header at
> fixed position from end of elf executable. If you have better
> solution...
Sure, but I need to do lots of reading before I could code it.
> Here is trivial uitility for adding headers: (GPL) [It needs to be
> improved _very_ much in order to be usefull. We should probably aim
> for compatibility with similar utilities on other systems. Also
> utility for listing these info is needed.]
Speaking of which... how would you like the ps program to show them?
I can have ps print capabilities as soon as I find a good format.
(hex is not friendly, but text is far too wide -- preferences?)
> And now, here is the diff. This is more proof of concept etc rather
> than anything else... Still it would be nice to see it in 2.2.6.
...
> +/* Capabilities support
> + */
> +struct elf_capabilities {
> + Elf32_Word signature;
> + Elf32_Word capabilities;
> + Elf32_Word flags;
> +#define ECF_MAKE_EUID_UID 1
> +#define ECF_MAKE_EUID_XUID 2
> + Elf32_Word xuid;
> +};
...
> + if (cap.flags & ECF_MAKE_EUID_UID)
> + bprm->e_uid = current->uid;
> + if (cap.flags & ECF_MAKE_EUID_XUID)
> + bprm->e_uid = cap.xuid;
> + cap_mask( bprm->cap_effective, cap.capabilities );
> + cap_mask( bprm->cap_permitted, cap.capabilities );
> +#if 0
> + cap_mask( current->cap_inheritable, cap.capabilities );
> +#endif
I think a tagged format might be better. You need 3 capabilities
entries, and they are likely to grow in size with time. Someone
will surely want to add auditing, etc.
Something like this:
signature
flags
effective capabilities type code
effective capabilities length
effective capabilities data
[same thing for permitted]
[same thing for inheritable]
uid type code
uid mapping
uid array length
uid list
[same for primary gid]
addgid type code (additional supplementary group IDs)
addgid array length
addgid list
[same thing to remove undesired supplementary group IDs]
I could do an editor on the weekend. Would it help?
(no nice ELF section support unless I get instructions)
In the kernel, the UID handling goes like this:
int uids[8];
uids[0] = current->uid;
uids[1] = current->euid;
uids[2] = current->suid;
uids[3] = current->fsuid;
uids[4] = cap.uids[0]; /* must add length checking */
uids[5] = cap.uids[1];
uids[6] = cap.uids[2];
uids[7] = cap.uids[3];
foo->uid = uids[(cap.uidmap >> 0) & 7];
foo->euid = uids[(cap.uidmap >> 4) & 7];
foo->suid = uids[(cap.uidmap >> 8) & 7];
foo->fsuid = uids[(cap.uidmap >> 12) & 7];
As you can see, this lets the executable select all 4 UID values
from those of the executable or from those of the process.
There is room to add a login ID or audit ID as an additional source.
-
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/