[gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 4314 bytes --]

i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
most settings are now defaults
-mike

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: fcaps.eclass
# @MAINTAINER:
# Constanze Hausner <constanze@gentoo.org>
# base-system@gentoo.org
# @BLURB: function to set POSIX file-based capabilities
# @DESCRIPTION:
# This eclass provides a function to set file-based capabilities on binaries.
#
# Due to probable capability-loss on moving or copying, this happens in
# pkg_postinst-phase (at least for now).
#
# @EXAMPLE:
# You can manually set the caps on ping and ping6 by doing:
# @CODE
# pkg_postinst() {
# 	fcaps cap_net_raw bin/ping bin/ping6
# }
# @CODE
#
# Or set it via the global ebuild var FILECAPS:
# @CODE
# FILECAPS=(
# 	cap_net_raw bin/ping bin/ping6
# )
# @CODE

if [[ ${___ECLASS_ONCE_FCAPS} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_FCAPS="recur -_+^+_- spank"

IUSE="+filecaps"

DEPEND="filecaps? ( sys-libs/libcap )"

# @ECLASS-VARIABLE: FILECAPS
# @DEFAULT_UNSET
# @DESCRIPTION:
# An array of fcap arguments to use to automatically execute fcaps.  See that
# function for more details.
#
# All args are consumed until the '--' marker is found.  So if you have:
# @CODE
# 	FILECAPS=( moo cow -- fat cat -- chubby penguin )
# @CODE
#
# This will end up executing:
# @CODE
# 	fcaps moo cow
# 	fcaps fat cat
# 	fcaps chubby penguin
# @CODE
#
# Note: If you override pkg_postinst, you must call fcaps_pkg_postinst yourself.

# @FUNCTION: fcaps
# @USAGE: [-o <owner>] [-g <group>] [-m <mode>] <capabilities> <file[s]>
# @DESCRIPTION:
# Sets the specified capabilities on the specified files.
#
# The caps option takes the form as expected by the cap_from_text(3) man page.
# If no action is specified, then "=ep" will be used as a default.
#
# If the file is a relative path (e.g. bin/foo rather than /bin/foo), then the
# appropriate path var ($D/$ROOT/etc...) will be prefixed based on the current
# ebuild phase.
#
# If the system is unable to set capabilities, it will use the specified user,
# group, and mode (presumably to make the binary set*id).  The defaults there
# are root:root and 4711.  Otherwise, the ownership and permissions will be
# unchanged.
fcaps() {
	debug-print-function ${FUNCNAME} "$@"

	# Process the user options first.
	local owner='root'
	local group='root'
	local mode='4711'

	while [[ $# -gt 0 ]] ; do
		case $1 in
		-o) owner=$2; shift;;
		-g) group=$2; shift;;
		-m) mode=$2; shift;;
		*) break;;
		esac
		shift
	done

	[[ $# -lt 2 ]] && die "${FUNCNAME}: wrong arg count"

	local caps=$1
	[[ ${caps} == *[-=+]* ]] || caps+="=ep"
	shift

	local root
	case ${EBUILD_PHASE} in
	compile|install|preinst)
		root=${ED:-${D}}
		;;
	postinst)
		root=${EROOT:-${ROOT}}
		;;
	esac

	# Process every file!
	local file out
	for file ; do
		[[ ${file} != /* ]] && file="${root}${file}"

		if use filecaps ; then
			# Try to set capabilities.  Ignore errors when the
			# fs doesn't support it, but abort on all others.
			debug-print "${FUNCNAME}: setting caps '${caps}' on '${file}'"

			if ! out=$(LC_ALL=C setcap "${caps}" "${file}" 2>&1) ; then
				if [[ ${out} != *"Operation not supported"* ]] ; then
					eerror "Setting caps '${caps}' on file '${file}' failed:"
					eerror "${out}"
					die "could not set caps"
				else
					local fstype=$(stat -f -c %T "${file}")
					ewarn "Could not set caps on '${file}' due to missing filesystem support."
					ewarn "Make sure you enable XATTR support for '${fstype}' in your kernel."
				fi
			else
				# Sanity check that everything took.
				setcap -v "${caps}" "${file}" >/dev/null \
					|| die "Checking caps '${caps}' on '${file}' failed"

				# Everything worked.  Move on to the next file.
				continue
			fi
		fi

		# If we're still here, setcaps failed.
		debug-print "${FUNCNAME}: setting owner/mode on '${file}'"
		chown "${owner}:${group}" "${file}" || die
		chmod ${mode} "${file}" || die
	done
}

# @FUNCTION: fcaps_pkg_postinst
# @DESCRIPTION:
# Process the FILECAPS array.
fcaps_pkg_postinst() {
	local arg args=()
	for arg in "${FILECAPS[@]}" "--" ; do
		if [[ ${arg} == "--" ]] ; then
			fcaps "${args[@]}"
			args=()
		else
			args+=( "${arg}" )
		fi
	done
}

EXPORT_FUNCTIONS pkg_postinst

fi

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

This might be a silly question already answered in a previous thread,
but why make it filecaps a USE-enable capability at all ?

It's not like libcap is a big dependency and it's not like this is an
attempt to make the system more secure by according just the privileges
needed for apps to work as intended, right ?

If the USE flag must stay, how is it different that current caps USE
flag ? It applies and not just enables support but is that relevant to
the purpose at hand ?

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On 26/01/2013 01:10, Gilles Dartiguelongue wrote:
> If the USE flag must stay, how is it different that current caps USE
> flag ? It applies and not just enables support but is that relevant to
> the purpose at hand ?

filecaps require the kernel to support security xattrs on the
filesystems used for install (and merge, iirc, not sure if the eclass
works this around — at the time it was written, tmpfs didn't support
xattr; now it does so it does support filecaps), and the
filesystem-based capabilities as well (which might be forced-on right
now but I'm not going to bet on it).

E.g.:

CONFIG_EXT4_FS_XATTR=y
CONFIG_TMPFS_XATTR=y

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 4022 bytes --]

On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote:
> It's not like libcap is a big dependency

true, but not everyone needs this, nor can everyone leverage it (caps).  it's 
a linux-centric implementation and is dependent upon filesystem support being 
available & enabled.

that doesn't entirely justify making it a USE flag (since the code already has 
runtime fallback logic for when the fs doesn't support things), but since the 
USE is low overhead and leverages logic that already has to be there, i have 
no problem keeping it.  plus it defaults to on.

> and it's not like this is an
> attempt to make the system more secure by according just the privileges
> needed for apps to work as intended, right ?

mmm that's exactly what this is

> If the USE flag must stay, how is it different that current caps USE
> flag ? It applies and not just enables support but is that relevant to
> the purpose at hand ?

USE=caps is for apps to control their runtime privs (there's also packages 
which want to query things like coreutils, but let's ignore those).  in order 
to grant themselves reduced privs, they have to start with them in the first 
place -- capabilities allows you to remove privs from yourself, not extend 
them.  that's accomplished (classically & today) by having the program set*id.  
thus, when the program is run, it is (typically) launched as the root user 
which means they have the full capset.

if the package supports USE=caps, then it means the program is intelligent 
enough to know what capabilities it needs and so it can drop all of the rest 
before executing the main body of code.  if it doesn't support USE=caps, then 
it either tries to do all the superuser stuff first and then drop its uid back 
down to the executing user's.  if it can't do that, then it has to be super 
careful about everything it does.  some packages (like openssh and Google 
Chrome -- not great examples, but good enough) implement even more complicated 
setups with privilege separation where there is IPC between a privileged 
process and an unprivileged one.

either way, obviously the more code you have, the harder it is to make sure 
you get it right (and history is littered with vulns where people didn't).  so 
wouldn't it be nice if you could set the required capabilities on a binary and 
drop the set*id entirely ?  that's what USE=filecaps gets us.  now there is no 
time frame within which you can attack and gain elevated privileges -- the 
kernel will have the new program start off with the right capset from the very 
beginning.

obviously i'm glossing over bugs where people can get get a program to do 
things it shouldn't with the capset it didn't drop, but that scenario exists 
regardless of set*id and USE=caps behavior.  in the ideal world:
 - USE=filecaps so you start only with the caps you need
 - not be set*id at all
 - do all the things at the very beginning that require the elevated caps
 - support USE=caps so you can then drop all of your elevated caps
 - run like normal and process all user input

as an example, let's look at ping.  we give it set*id because people want to 
be able to do something innocuous as `ping 192.168.0.1` w/out `sudo` first.  in 
order to send ICMP_ECHO packets, it needs to create a SOCK_RAW socket which 
the kernel doesn't allow random users to create (otherwise they could generate 
arbitrary packets on the network).  when USE=-cap, the first thing ping does is 
create the socket, then drop the root uid.  when USE=cap, the first thing it 
does is drop all of its permitted caps to the bare min what it needs in the 
future, and then sets the effective even lower.  when it needs to open the 
socket, it sets the effective to what it needs, opens the socket, and then sets 
the effective lower again.  rinse/repeat.

at least, this is all my understanding of things.  i could be completely 
wrong, so feel free to correct something if you notice it.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: fcaps.eclass: bringing filesystem capabilities to the tree

[Duncan]

Mike Frysinger posted on Sat, 26 Jan 2013 02:46:12 -0500 as excerpted:

> if the package supports USE=caps, then it means the program is
> intelligent enough to know what capabilities it needs and so it can drop
> all of the rest before executing the main body of code.

> wouldn't it be nice if you could set the required capabilities on a
> binary and drop the set*id entirely ?  that's what USE=filecaps gets us.

Very useful summary.  Thanks. =:^)

I had all the pieces from various reading, but they were more in a heap 
than assembled, and just the other day I was trying to assemble them into 
something coherent (triggered by this thread, IIRC), but discovered I 
still needed a bit of help.  This was exactly what I needed for the 
accumulated information to all fall into place!  Thanks again! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Fri, 25 Jan 2013 18:51:44 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> # Or set it via the global ebuild var FILECAPS:
> # @CODE
> # FILECAPS=(
> # 	cap_net_raw bin/ping bin/ping6
> # )
> # @CODE

Please don't. We have enough eclasses randomly exporting
pkg_postinst().

The FILECAPS array consumes the same amount of space as pkg_postinst()
phase declaration. There's no real benefit to this automagic.

Yet, the phase function exported is *forced* to every single eclass
consumer. Therefore, you are implicitly adding lines for people who
will have to make sure that every single other pkg_postinst() you
clobbered is called.

Of course, assuming people would actually notice some of the other
useless pkg_postinst() phases being clobbered...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On 26/01/2013 08:46, Mike Frysinger wrote:
> 
> at least, this is all my understanding of things.  i could be completely 
> wrong, so feel free to correct something if you notice it.

All looks good to me, but just because somebody is going to wonder this
I would add a few words:

While this is basically the same underlying idea of selinux and rbac, it
is much more limited in scope. In particular instead of telling each
program exactly what they can or cannot do, we're giving them a broad
spectrum of privileges (but much narrower than what a setuid root
program would have). This is both less rewarding in term of security,
and less headache-prone.

Indeed most of the capabilities currently allowed are pretty much "do
something almost like root" — so for instance `tcpdump` needs
CAP_NET_ADMIN that does... almost everything with the network, while
`ping` would just use CAP_NET_RAW and be able to send out the ICMP ECHO
packets just fine. A web server, or any other server using privileged
TCP/UDP ports (<1024) would need instead CAP_NET_BIND_SERVICE.

All these settings allow tools to run as users who generally don't have
said capabilities, and yet be able to execute higher-level features. As
Mike said, this is just to replace setuid (and if you got selinux, you
go one step further because you can for instance give
CAP_DAC_READ_SEARCH to a tool, but also verify that it doesn't go
randomly reading stuff out of an user's home.

There's also a different kind of capabilities, in theory, relating to
users instead and using PAM — but I never got to get it working :(

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Rich Freeman]

On Sat, Jan 26, 2013 at 11:01 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
>
> There's also a different kind of capabilities, in theory, relating to
> users instead and using PAM — but I never got to get it working :(

I naively assumed that if you edit /etc/security/capability.conf this
would set the per-user capabilities.  However, I have not actually
tried this.  I guess our pam configuration/etc isn't set to check this
file?

Rich

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Diego Elio Pettenò]

On 26/01/2013 17:13, Rich Freeman wrote:
> I naively assumed that if you edit /etc/security/capability.conf this
> would set the per-user capabilities.  However, I have not actually
> tried this.  I guess our pam configuration/etc isn't set to check this
> file?

pambase is not enabling pam_caps, so the file is ignored, at least for
what I last knew.

pambase needs to be restructured, but as I said before it's a task that
for me is a PITA as I don't really use much about it, and it takes a lot
of time and work to set up properly.

I've been open for a while to be hired by somebody who has needs for a
more precise PAM configuration in Gentoo, but no dice there.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 639 bytes --]

On Saturday 26 January 2013 08:21:37 Michał Górny wrote:
> On Fri, 25 Jan 2013 18:51:44 -0500 Mike Frysinger wrote:
> > # Or set it via the global ebuild var FILECAPS:
> > # @CODE
> > # FILECAPS=(
> > # 	cap_net_raw bin/ping bin/ping6
> > # )
> > # @CODE
> 
> Please don't. We have enough eclasses randomly exporting
> pkg_postinst().

i'm not terribly concerned for two reasons:
 - pkg_postinst should be discouraged in favor of pkg_preinst since postinst 
can't call `die`
 - most of the ebuilds that will be using fcaps don't use eclasses that export 
pkg_postinst thus they should be able to leverage it fine
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Doug Goldstein]

On Fri, Jan 25, 2013 at 5:51 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
> most settings are now defaults
> -mike
>

Good deal. Good idea on using USE=filecaps instead of USE=caps due to
the requirements. Once this hits the tree I'll likely start using it
for app-emulation/qemu.

-- 
Doug Goldstein

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 291 bytes --]

On Friday 25 January 2013 18:51:44 Mike Frysinger wrote:
> i've taken Constanze' work and rewritten it a bit to be easier to use (imo)
> as most settings are now defaults

merged.  i'll move iputils over to it first and if there aren't any problems, 
i'll move more over to it.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Kacper Kowalik]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On 27.01.2013 18:26, Mike Frysinger wrote:
> On Friday 25 January 2013 18:51:44 Mike Frysinger wrote:
>> i've taken Constanze' work and rewritten it a bit to be easier to use (imo)
>> as most settings are now defaults
> 
> merged.  i'll move iputils over to it first and if there aren't any problems, 
> i'll move more over to it.
> -mike

Could you also add 'filecaps' to use.desc, please?
Kacper


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Le samedi 26 janvier 2013 à 02:46 -0500, Mike Frysinger a écrit :
> On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote:
> > It's not like libcap is a big dependency
> 
> true, but not everyone needs this, nor can everyone leverage it (caps).  it's 
> a linux-centric implementation and is dependent upon filesystem support being 
> available & enabled.
> 
> that doesn't entirely justify making it a USE flag (since the code already has 
> runtime fallback logic for when the fs doesn't support things), but since the 
> USE is low overhead and leverages logic that already has to be there, i have 
> no problem keeping it.  plus it defaults to on.

hum, ok.

> > and it's not like this is an
> > attempt to make the system more secure by according just the privileges
> > needed for apps to work as intended, right ?
> 
> mmm that's exactly what this is
> 
> > If the USE flag must stay, how is it different that current caps USE
> > flag ? It applies and not just enables support but is that relevant to
> > the purpose at hand ?

[...]

In summary, USE=caps if for stripping down from all to the bare minimum
caps while USE=filecaps should allow us to provide bare minimum required
capabilities from the start.

If so, maybe this could be the same USE flag ? I would understand if we
wanted to keep it separated to avoid potential confusion about the
actual impact on packages though.


-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: fcaps.eclass: bringing filesystem capabilities to the tree

[Duncan]

Mike Frysinger posted on Fri, 25 Jan 2013 18:51:44 -0500 as excerpted:

> else
> 	local fstype=$(stat -f -c %T "${file}")
> 	ewarn "Could not set caps on '${file}' due to missing filesystem support."
> 	ewarn "Make sure you enable XATTR support for '${fstype}' in your kernel."
> fi

This needs a bit more information, please.
I had XATTR support enabled, but it wasn't enough.

For at least reiserfs, and presumably for ext4, since it has
similar kconfig options, *_FS_XATTR isn't enough,
*_FS_SECURITY must be enabled as well.

(*_FSPOSIX_ACL did NOT need to be enabled, however.)

So:

ewarn "Make sure you enable XATTR and SECURITY attribute
support for ${fstype} in your kernel."

Unfortunately, kernel-help for *_FS_SECURITY implies that it only needs
to be enabled for SELinux or the like, recommending that it be disabled
if you're not running such modules.  Is it worth filing an upstream
mainline kernel bug on that as well, suggesting that it mention file-caps
as well?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: fcaps.eclass: bringing filesystem capabilities to the tree

[Diego Elio Pettenò]

On 29/01/2013 13:14, Duncan wrote:
> For at least reiserfs, and presumably for ext4, since it has
> similar kconfig options, *_FS_XATTR isn't enough,
> *_FS_SECURITY must be enabled as well.

Good point, even I forgot that it's part of security labels rather than
xattr strict (funnily enough, PaX wasn't last time I checked).

> Unfortunately, kernel-help for *_FS_SECURITY implies that it only needs
> to be enabled for SELinux or the like, recommending that it be disabled
> if you're not running such modules.  Is it worth filing an upstream
> mainline kernel bug on that as well, suggesting that it mention file-caps
> as well?

Most likely a good idea.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/