Related, but no.
To my knowledge this is currently available on the following platforms:
Debian stable
Ubuntu
Gentoo
Fedora
I'm not sure that it made it into rhel/centos 6.
Anything that has kernel 2.6.32+ and a libcap2 package available.
Topic: [PULL] Capabilities Bounding Set Support (Linux-specific) (Read 1600 times)
Is this the same mechanism as used by Fedora's SELinux (security enhanced linux)?
I was asked to create a forum thread so here it is.
In Linux 2.6.32+ the linux kernel had some fun changes to the posix1.e implementation in regards to how the CAP_SETPCAP capability is interpreted by the system and the addition of filesystem meta data support to enable capabilities instead of just blanket suid/sgid binaries.
This patch arose out of discussions in #bitcoin-dev.
Various proposed wallet encryption methods were being discussed at the time by BlueMatt and a few others. The (straw man) argument was proposed that if an attacker were able to get root on the machine any of the proposed methods would be completely compromised. (Re: decode on launch vs decode on txn creation, let's not rehash this discussion here as it is outside of the scope of this patch.)
This is merely one method of mitigating such risks through bitcoind itself. By clearing the bounding set and setting these flags in PR_SET_SECUREBITS the kernel will not let this process ever gain escalated privs. This means that even if, say, an attack vector which allowed for remote execution in bitcoin was found, and let's say the system it is running on has some zero-day exploit in an suid binary. (or a lazy admin, not that I endorse this) Even if the code was executed, the kernel would ignore the setuid flags on the binary and it would still run as whatever user bitcoind was launched at.
The patch as implemented is fairly straight forward.
As written, even if enabled, this patch does absolutely nothing unless the process when launched has the CAP_SETPCAP capability. There are 3 (simple, there are a few others) ways for the process to be created in this way:
1) Launch bitcoind as root. HORRIBLE
2) Set bitcoind setuid root. HORRIBLE
3) Use the setcap utility to: setcap cap_setpcap=eip bitcoind; AWESOME
The only recommended method is the last. This capability is required in order to modify the bounding set of yourself. Please note that if you read older documentation this capability sounds scarier than it is pre-2.6.32 and file metadata capability support this capability would let you modify the capabilities of any process on the machine. This is not the case in 2.6.32+.
Side effects/regressions:
With this option built if bitcoind is launched as root to say, bind to a port <1024 it will no longer be able to do this as this patch completely removes the special meaning of uid 0 in the running process and all children/threads.
This patch does not enable this functionality in the bitcoin gui client. I am not sure if that is worth pursuing; but, I am just not familiar with wxWidgets and did not want to stick it in the "wrong" place.
Pull request:
https://github.com/bitcoin/bitcoin/pull/202
In Linux 2.6.32+ the linux kernel had some fun changes to the posix1.e implementation in regards to how the CAP_SETPCAP capability is interpreted by the system and the addition of filesystem meta data support to enable capabilities instead of just blanket suid/sgid binaries.
This patch arose out of discussions in #bitcoin-dev.
Various proposed wallet encryption methods were being discussed at the time by BlueMatt and a few others. The (straw man) argument was proposed that if an attacker were able to get root on the machine any of the proposed methods would be completely compromised. (Re: decode on launch vs decode on txn creation, let's not rehash this discussion here as it is outside of the scope of this patch.)
This is merely one method of mitigating such risks through bitcoind itself. By clearing the bounding set and setting these flags in PR_SET_SECUREBITS the kernel will not let this process ever gain escalated privs. This means that even if, say, an attack vector which allowed for remote execution in bitcoin was found, and let's say the system it is running on has some zero-day exploit in an suid binary. (or a lazy admin, not that I endorse this) Even if the code was executed, the kernel would ignore the setuid flags on the binary and it would still run as whatever user bitcoind was launched at.
The patch as implemented is fairly straight forward.
As written, even if enabled, this patch does absolutely nothing unless the process when launched has the CAP_SETPCAP capability. There are 3 (simple, there are a few others) ways for the process to be created in this way:
1) Launch bitcoind as root. HORRIBLE
2) Set bitcoind setuid root. HORRIBLE
3) Use the setcap utility to: setcap cap_setpcap=eip bitcoind; AWESOME
The only recommended method is the last. This capability is required in order to modify the bounding set of yourself. Please note that if you read older documentation this capability sounds scarier than it is pre-2.6.32 and file metadata capability support this capability would let you modify the capabilities of any process on the machine. This is not the case in 2.6.32+.
Side effects/regressions:
With this option built if bitcoind is launched as root to say, bind to a port <1024 it will no longer be able to do this as this patch completely removes the special meaning of uid 0 in the running process and all children/threads.
This patch does not enable this functionality in the bitcoin gui client. I am not sure if that is worth pursuing; but, I am just not familiar with wxWidgets and did not want to stick it in the "wrong" place.
Pull request:
https://github.com/bitcoin/bitcoin/pull/202
Jump to: