Hello.
I recently upgraded from 3.10.7 on a long-running box to 3.12.8 on a
new box. I have been using file capabilities for a long time, so that
processes do not need to start as root and drop unnecessary privileges
later.
For example, there is no reason for my bind9 nameservers to start as
root, except to bind() port 53 and 953. What I did in this case was to
chown it to root:named and chmod it to 0750 and assign
CAP_NET_BIND_SERVICE to it, it then starts as named and works fine.
I haven't had any issues with this for easily a year, until now. No
matter what I do on this new machine, I cannot get file capabilities
to 'work'. They are set fine, they are read back fine, but they don't
do anything. I have attached my kernel boot log, its configuration and
a test program (build with -std=c99 -lcap-ng).
My problem follows:
# strace -f setcap cap_net_bind_service+eip /usr/local/bin/caps 2>&1 \
| grep xattr
setxattr("/usr/local/bin/caps", "security.capability", \
"\x01\x00\x00\x02\x00\x04\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00 \
\x00\x00\x00\x00", 20, 0) = 0
# getcap /usr/local/bin/caps
/usr/local/bin/caps = cap_net_bind_service+eip
$ /usr/local/bin/caps
Effective capabilities: (none)
Permitted capabilities: (none)
And the CapEff and CapPrm fields in /proc/pid/status are all zero!
There is nothing in the kernel log, before or after the execution,
that is relevant to capabilities. Some additional information:
# cat /proc/version
Linux version 3.12.8 (root@citadel) (gcc version 4.7.3 (Gentoo \
Hardened 4.7.3-r1 p1.4, pie-0.5.5)) #1 SMP Tue Jan 21 12:26:18 \
UTC 2014
# cat /proc/sys/kernel/tainted
0
# mount | grep ' / '
/dev/sda2 on / type ext4 (rw,nosuid,relatime,data=ordered)
# equery belongs $(which setcap)
sys-libs/libcap-2.22 (/sbin/setcap)
Extended attributes do indeed work:
# echo testing > /usr/local/bin/test
# chown root:root /usr/local/bin/test
# chmod 0600 /usr/local/bin/test
# strace -f setfacl -m u:aaron:r /usr/local/bin/test \
2>&1 | grep xattr
getxattr("/usr/local/bin/test", "system.posix_acl_access", \
0x7fffffffce00, 132) = -1 ENODATA (No data available)
setxattr("/usr/local/bin/test", "system.posix_acl_access", \
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x02\x00\x04\x00 \
\xe8\x03\x00\x00\x04\x00\x00\x00\xff\xff\xff\xff\x10\x00\x04\x00 \
\xff\xff\xff\xff \x00\x00\x00 \xff\xff\xff\xff", 44, 0) = 0
$ cat /usr/local/bin/test
testing
Does anyone have an insight here? I'm about ready to pull my hair out
over this. I've been going at this for 3 days now...
I am subscribed, but please CC me in replies so that they come to my
attention immediately.
Thanks in advance,
Aaron Jones.
Quoting Aaron Jones ([email protected]):
>
> Hello.
>
> I recently upgraded from 3.10.7 on a long-running box to 3.12.8 on a
> new box. I have been using file capabilities for a long time, so that
> processes do not need to start as root and drop unnecessary privileges
> later.
>
> For example, there is no reason for my bind9 nameservers to start as
> root, except to bind() port 53 and 953. What I did in this case was to
> chown it to root:named and chmod it to 0750 and assign
> CAP_NET_BIND_SERVICE to it, it then starts as named and works fine.
>
> I haven't had any issues with this for easily a year, until now. No
> matter what I do on this new machine, I cannot get file capabilities
> to 'work'. They are set fine, they are read back fine, but they don't
> do anything. I have attached my kernel boot log, its configuration and
> a test program (build with -std=c99 -lcap-ng).
>
> My problem follows:
>
> # strace -f setcap cap_net_bind_service+eip /usr/local/bin/caps 2>&1 \
> | grep xattr
> setxattr("/usr/local/bin/caps", "security.capability", \
> "\x01\x00\x00\x02\x00\x04\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00 \
> \x00\x00\x00\x00", 20, 0) = 0
>
> # getcap /usr/local/bin/caps
> /usr/local/bin/caps = cap_net_bind_service+eip
>
> $ /usr/local/bin/caps
> Effective capabilities: (none)
> Permitted capabilities: (none)
Hm, I'm running Ubuntu 3.13.0-5-generic and I do get
serge@tp:~/test$ ./caps
Effective capabilities:
net_bind_service
Permitted capabilities:
net_bind_service
Any chance (grasping for straws here) that the hardening patches are
interfering? Can you try hand-building an upstream kernel to test
with?
-serge
On 26/01/14 16:22, Serge E. Hallyn wrote:
> Hm, I'm running Ubuntu 3.13.0-5-generic and I do get
>
> serge@tp:~/test$ ./caps
> Effective capabilities:
> net_bind_service
> Permitted capabilities:
> net_bind_service
>
> Any chance (grasping for straws here) that the hardening patches
> are interfering? Can you try hand-building an upstream kernel to
> test with?
I downloaded a vanilla 3.12.8 tree directly from kernel.org
for the purposes of my previous post. I was running that kernel
then... I also have the same problem with the hardened kernel now.
I'm at a loss as to why it doesn't work on 3.12.8, but it does on
3.10.7, hardening patches or not.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I have isolated the problem. File capabilities are not assigned when
the program being executed is located on a filesystem mounted with
the "nosuid" option.
This seems counter-intuitive; a fully capability-based system would
not use setuid binaries... so a logical thing to do would be to
prevent the setuid bits from doing anything, which is what the
nosuid flag is for, no?
Or am I missing something?
Can we get a config flag to toggle this behaviour?
Aaron Jones.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS8T0RAAoJEG6FTA+q1M6knGgP/i6UattzXwpFM80Q32GelaTe
cu8JQLY/BCjN/vICit7VTyAFkxxy5sKxBZB/YYBRa9AlRiMR0MjPb2lhL0q1HJeW
1hl0/91/Mq7jDRC31y5UXCLv9P2iqoM4gZP4eh2b0xOXtZhOPstX24lIxTWIxQ/6
rDJkW6pht9x2NWZIlpuxW8qFpaTZ7iw9zAYEs8Jm/PyXaRi07vY2CJhk+WzdrUZq
+NKA9H5ZmaQlyyjBEHA5AEPm2xqxGz8PvI4UhKAzxTC2dBeGL26zYmIxXWsTnq5Z
reyM0vqGzqLPyYh02mUz+8f72UtYEogZQGdhlfyqEObcXM5FW7JyA+NWi7UIxVB4
qJaUX/h/CllIXapDklMpfxpWeM/0lI8vOnF6z+PFBhJFN7+2bEnmPHWvVPqYr3Uu
EhkOjHYT5GNX0s42jR6Y3etWNel+whISyDAYd203lewqFmAKapoDSJgY8+wYdq/Y
s6kiSMupkXcS1vC4qDAprpcXGOBjzSNL+iiwYKgzStuTXNEvRqn4eS955UwCI1/k
PzYbXMDUuqZbL8446IrSpYnmzwy3YJvNqFX5kpFdvmwk1j75oXkJ/09O+hN4L2bZ
45teFqvTw4FrZGltvKt52iZC8+gkuPnpY1nujSpLnQMM28zSn1TNYXScmaQinjVb
TjuUQDZ3NlE7XSZp20Jp
=LOIA
-----END PGP SIGNATURE-----
Quoting Aaron Jones ([email protected]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I have isolated the problem. File capabilities are not assigned when
> the program being executed is located on a filesystem mounted with
> the "nosuid" option.
>
> This seems counter-intuitive; a fully capability-based system would
> not use setuid binaries...
Not strictly true. setuid really just means 'change uid'. The fact
that it can also raise/lower capability sets just muddles the issue.
If you want that behavior stopped you can do so using
SECBIT_NO_SETUID_FIXUP.
> so a logical thing to do would be to
> prevent the setuid bits from doing anything, which is what the
> nosuid flag is for, no?
>
> Or am I missing something?
>
> Can we get a config flag to toggle this behaviour?
I think generally when people mount nosuid it is to prevent
an untrusted source (usb stick, whatever) from providing a
untrusted but privileged program. Be that through setuid-root
binaries or file capabilities.
-serge