FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-05-2011, 12:24 PM
Constanze Hausner
 
Default eclass for handling of file-based capabilities

Hello,

last GSoC I developed an eclass for the handling of file-based
capabilities [1]. One should be able to set file-caps for the binary from
the src_install phase. The eclass handles the setting of the caps and
also applies a fallback file-mode, if the caps-setting goes wrong.

I would be happy, if you guys and gals could take a look at it,
and review it .

It uses a new global use-flag (filecaps) so it wouldn't collide with
the caps use-flag and the corresponding old handling of file-caps.

The git repository, which also includes a manpage and some tests for the eclass,
is available here [2].
I'm going to update the eclass with your patches there.

Cheers,
Constanze

[1] http://www.friedhoff.org/posixfilecaps.html
[2] https://github.com/constanze/GSoC2010_Gentoo_Capabilities
# Copyright 2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: fcaps.eclass
# @MAINTAINER: Constanze Hausner <constanze@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).

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

# @FUNCTION: fcaps
# @USAGE: fcaps {uid:gid} {file-mode} {cap1[,cap2,...]} {file}
# @RETURN: 0 if all okay; non-zero if failure and fallback
# @DESCRIPTION:
# fcaps sets the specified capabilities in the effective and permitted set of
# the given file. In case of failure fcaps sets the given file-mode.
fcaps() {
debug-print-function ${FUNCNAME} "$@"
debug-print "${FUNCNAME}: Trying to set capabilities for ${4}"
local uid_gid=$1
local perms=$2
export fallbackFileMode=$perms
local capset=$3
local path=$4
if [ $# -eq 5 ]; then
local set_mode=$5
else
debug-print "${FUNCNAME}: no set-mode provided, setting it to ep"
#if there is no set_mode provided, it is set to true
local set_mode=1
fi

#set owner/group
debug-print "${FUNCNAME}: setting owner and group to ${uid_gid}"
chown $uid_gid $path
if [ $? -ne 0 ]; then
eerror "chown "$uid_gid" "$path" failed."
return 2
fi

#set file-mode including suid
debug-print "${FUNCNAME}: setting file-mode ${perms}, including suid"
chmod $perms $path
if [ $? -ne 0 ]; then
eerror "chmod "$perms" "$path" failed."
return 3
fi

#if filecaps is not enabled all is done
use !filecaps && return 0

#if libcap is not installed caps cannot be set
if [ ! -f "/sbin/setcap" ]; then
debug-print "${FUNCNAME}: libcap not installed, could not set caps"
return 4
fi

#Check for set mode
if [ $set_mode -eq 1 ]; then
debug-print "${FUNCNAME}: set-mode = ep"
local sets="=ep"
else
debug-print "${FUNCNAME}: set-mode = ei"
local sets="=ei"
fi

#set the capability
debug-print "${FUNCNAME}: setting capabilities"
setcap "$capset""$sets" "$path" &> /dev/null

#check if the capabilitiy got set correctly
debug-print "${FUNCNAME}: checking capabilities"
setcap -v "$capset""$sets" "$path" &> /dev/null

local res=$?

#if caps could be set, remove suid-bit
if [ $res -eq 0 ]; then
debug-print "${FUNCNAME}: caps were set, removing suid-bit"
chmod -s $path
else
debug-print "${FUNCNAME}: caps could not be set"
ewarn "setcap "$capset" "$path" failed."
ewarn "Check your kernel and filesystem."
ewarn "Fallback file-mode was set."
fi

return $res
}
 
Old 03-05-2011, 04:15 PM
Ciaran McCreesh
 
Default eclass for handling of file-based capabilities

On Sat, 5 Mar 2011 14:24:22 +0100
Constanze Hausner <constanze@gentoo.org> wrote:
> It uses a new global use-flag (filecaps) so it wouldn't collide with
> the caps use-flag and the corresponding old handling of file-caps.

You're requiring special package manager behaviour if that flag is set?

--
Ciaran McCreesh
 
Old 03-05-2011, 04:41 PM
Constanze Hausner
 
Default eclass for handling of file-based capabilities

On 17:15 Sat 05 Mar , Ciaran McCreesh wrote:
> On Sat, 5 Mar 2011 14:24:22 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
> > It uses a new global use-flag (filecaps) so it wouldn't collide with
> > the caps use-flag and the corresponding old handling of file-caps.
>
> You're requiring special package manager behaviour if that flag is set?

Hi Ciaran,

I'm requiring, that the package manager preserves the xattrs, when
stripping the binary and when moving it from the sandbox to the live-fs.

I wrote a patch for portage, which I already sent to zmedico for
reviewal.

I hope I understood your question correctly .

Cheers,
Constanze
 
Old 03-05-2011, 04:44 PM
Ciaran McCreesh
 
Default eclass for handling of file-based capabilities

On Sat, 5 Mar 2011 18:41:46 +0100
Constanze Hausner <constanze@gentoo.org> wrote:
> > You're requiring special package manager behaviour if that flag is
> > set?
>
> I'm requiring, that the package manager preserves the xattrs, when
> stripping the binary and when moving it from the sandbox to the
> live-fs.

Currently we've got wording in PMS forbidding anything from relying
upon xattrs being preserved correctly, since that's what Portage did
when we wrote it. So if you're looking to change that, you'll need to
EAPI control it.

But it's not as simple as just requiring attributes to be preserved in
future EAPIs, since:

* some xattrs are fs specific

* some xattrs (selinux?) can't be copied

* some filesystems don't support xattrs at all, and the package manager
needs to support installing to them, even if the user is building on
a filesystem that does support it

* tar and xattrs is a massive problem, so how do binaries work?

I think it'd help if you provided a description of how all the above
(plus the other issues that I've forgotten about) can be handled.

--
Ciaran McCreesh
 
Old 03-06-2011, 10:01 AM
Brian Harring
 
Default eclass for handling of file-based capabilities

On Sat, Mar 05, 2011 at 02:24:22PM +0100, Constanze Hausner wrote:
> fcaps() {
> debug-print-function ${FUNCNAME} "$@"
> debug-print "${FUNCNAME}: Trying to set capabilities for ${4}"
> local uid_gid=$1
> local perms=$2
> export fallbackFileMode=$perms
> local capset=$3
> local path=$4

That export of fallbackFileMode looks pointless... clarify please.
Also, your arg count checking here means it's going to throw some
weird ass errors if people invoke it incorrectly. You likely want a

[ $# -ne 4 ] && die "wrong arg count"

thrown in there..


> if [ $# -eq 5 ]; then
> local set_mode=$5
> else
> debug-print "${FUNCNAME}: no set-mode provided, setting it to ep"
> #if there is no set_mode provided, it is set to true
> local set_mode=1
> fi
>
> #set owner/group
> debug-print "${FUNCNAME}: setting owner and group to ${uid_gid}"
> chown $uid_gid $path
> if [ $? -ne 0 ]; then
> eerror "chown "$uid_gid" "$path" failed."
> return 2
> fi
>
> #set file-mode including suid
> debug-print "${FUNCNAME}: setting file-mode ${perms}, including suid"
> chmod $perms $path

Arbitrary/user-controlled path's always need to be quoted...

> if [ $? -ne 0 ]; then
> eerror "chmod "$perms" "$path" failed."
> return 3
> fi
>
> #if filecaps is not enabled all is done
> use !filecaps && return 0
>
> #if libcap is not installed caps cannot be set
> if [ ! -f "/sbin/setcap" ]; then
> debug-print "${FUNCNAME}: libcap not installed, could not set caps"
> return 4
> fi
>
> #Check for set mode
> if [ $set_mode -eq 1 ]; then
> debug-print "${FUNCNAME}: set-mode = ep"
> local sets="=ep"
> else
> debug-print "${FUNCNAME}: set-mode = ei"
> local sets="=ei"
> fi

Shift this into the initial arg processing; eliminates the need for
set_mode and is simpler to follow.

>
> #set the capability
> debug-print "${FUNCNAME}: setting capabilities"

lay off the debug-print's a bit...

> setcap "$capset""$sets" "$path" &> /dev/null
>
> #check if the capabilitiy got set correctly
> debug-print "${FUNCNAME}: checking capabilities"
> setcap -v "$capset""$sets" "$path" &> /dev/null
>
> local res=$?
>
> #if caps could be set, remove suid-bit
> if [ $res -eq 0 ]; then
> debug-print "${FUNCNAME}: caps were set, removing suid-bit"
> chmod -s $path
> else
> debug-print "${FUNCNAME}: caps could not be set"
> ewarn "setcap "$capset" "$path" failed."
> ewarn "Check your kernel and filesystem."
> ewarn "Fallback file-mode was set."
> fi
>
> return $res
> }

I'd take a different approach here; this code basically assumes that
the PM knows of it- note the chmod -s. The use flag protection you
tried adding, without some profile hacks, is user modifiable- meaning
users can flip it on even if the PM doesn't support it.

Or consider that the code above is purely doing it's thing during the
install phase, specifically against whatever filesystem is used for
building- while capabilities might be able to be set there, it's
possible the final merge location won't support it. End result of
that is you'll get a setuid stripped binary merged to the
livefs lacking the caps- borkage. Or consider the inverse- the
buildroot can't do capabilities, but the livefs could. You get the
idea.

Instead, write the code so the PM has to export a marker in some
fashion to explicitly state "yes, I can do capabilities"- I'm
specifically suggestining checking for a callback function exposed to
the env.

If that function isn't there, then the PM can't do it- end of story.
If it is, the PM takes the args and will try to apply the
capabilities at the correct time- stripping setuid/setgid if it
succeeds.

Please go that route; and please do not stick "portage" into the
function name, something generic we can use for a later EAPI is
better.

Implementing it as I suggested has the nice side affect of not being
limited by PMS also, although it's an approach that still requires
planning for compatibility.

Thanks-
~brian
 
Old 03-06-2011, 03:34 PM
Constanze Hausner
 
Default eclass for handling of file-based capabilities

On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> On Sat, 5 Mar 2011 18:41:46 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
> > > You're requiring special package manager behaviour if that flag is
> > > set?
> >
> > I'm requiring, that the package manager preserves the xattrs, when
> > stripping the binary and when moving it from the sandbox to the
> > live-fs.
>
> Currently we've got wording in PMS forbidding anything from relying
> upon xattrs being preserved correctly, since that's what Portage did
> when we wrote it. So if you're looking to change that, you'll need to
> EAPI control it.
Yes, there would be the need for a new EAPI, if the caps should be set
from src_install and therefore need to be preserved by the PMS.
As long as there is no such garantee one could use the eclass to set the
caps from pkg_postinst. I know it's really ugly, but it would be a
start. Otherwise we will never be able to use caps.

> But it's not as simple as just requiring attributes to be preserved in
> future EAPIs, since:
>
> * some xattrs are fs specific
>
> * some xattrs (selinux?) can't be copied
I said something different than I thought, sorry. I only thought of the
caps and not other kinds of xattr, as I only require caps to be
preserved.
Caps do either work on a fs or they don't and they can be copied.

> * some filesystems don't support xattrs at all, and the package manager
> needs to support installing to them, even if the user is building on
> a filesystem that does support it
That's true, additionaly even if the fs is able to support xattr, there
are kernel options, which need to be set. I agree with you, that that's
a huge problem. We need to have a good fallback mechanism.

Zac metioned that we could have three modes for movefile:
1) no caps
2) tolerant mode, which does not fail if caps could not be copied
3) strict mode, which fails if caps can't be copied

ferringb metioned some kind of marker with which one can indicate xattr
support.

While GSoC I was not able to come up with a good fallback mechanism.
I'm going to give the new ideas some thought over the week and hopefully
come up with something good .

> * tar and xattrs is a massive problem, so how do binaries work?
tar can be patched to support xattrs. If we want to use caps, we will
have to apply those patches too. (iirc Fedora already uses such
patches).

> I think it'd help if you provided a description of how all the above
> (plus the other issues that I've forgotten about) can be handled.
I hope I cleared things up at least a bit .

Cheers,
constanze
 
Old 03-06-2011, 03:48 PM
Constanze Hausner
 
Default eclass for handling of file-based capabilities

On 03:01 Sun 06 Mar , Brian Harring wrote:
[snip]
Thanks for your feedback, your remarks were correct . I updated the
eclass appropriately.

> I'd take a different approach here; this code basically assumes that
> the PM knows of it- note the chmod -s. The use flag protection you
> tried adding, without some profile hacks, is user modifiable- meaning
> users can flip it on even if the PM doesn't support it.
>
> Or consider that the code above is purely doing it's thing during the
> install phase, specifically against whatever filesystem is used for
> building- while capabilities might be able to be set there, it's
> possible the final merge location won't support it. End result of
> that is you'll get a setuid stripped binary merged to the
> livefs lacking the caps- borkage. Or consider the inverse- the
> buildroot can't do capabilities, but the livefs could. You get the
> idea.
>
> Instead, write the code so the PM has to export a marker in some
> fashion to explicitly state "yes, I can do capabilities"- I'm
> specifically suggestining checking for a callback function exposed to
> the env.
>
> If that function isn't there, then the PM can't do it- end of story.
> If it is, the PM takes the args and will try to apply the
> capabilities at the correct time- stripping setuid/setgid if it
> succeeds.
>
> Please go that route; and please do not stick "portage" into the
> function name, something generic we can use for a later EAPI is
> better.
>
> Implementing it as I suggested has the nice side affect of not being
> limited by PMS also, although it's an approach that still requires
> planning for compatibility.
I'm currently in search of a good fallback mechanism respectivly a good
mechanism to deal with cap-setting in src_install. As I already said in
my mail to ciaran, I'm going to give the new ideas some thought .

Cheers,
constanze
 
Old 03-06-2011, 10:40 PM
Brian Harring
 
Default eclass for handling of file-based capabilities

On Sun, Mar 06, 2011 at 05:34:29PM +0100, Constanze Hausner wrote:
> On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > * tar and xattrs is a massive problem, so how do binaries work?
> tar can be patched to support xattrs. If we want to use caps, we will
> have to apply those patches too. (iirc Fedora already uses such
> patches).

For binpkg, the approach I mentioned would remove the need to for tar
to support xattrs- the same mechanism for the PM to tweak the perms
would be usable. So no need for tar/bsdtar to restore xattrs- it's
undesirable anyways since as I mentioned, if the cap couldn't be
applied for whatever reason it would result in a chmod -s binary being
installed.

For src, I'd strongly be against restoration there. It just opens up
way too many surprises- a simple example is a tarball carrying the
immutable flag. Xattrs really should be specified by the ebuild (and
applied by the PM) instead- far more controlled namely.

~harring
 
Old 03-07-2011, 07:44 AM
Michał Górny
 
Default eclass for handling of file-based capabilities

On Sun, 6 Mar 2011 17:34:29 +0100
Constanze Hausner <constanze@gentoo.org> wrote:

> On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > * some filesystems don't support xattrs at all, and the package
> > manager needs to support installing to them, even if the user is
> > building on a filesystem that does support it
>
> While GSoC I was not able to come up with a good fallback mechanism.
> I'm going to give the new ideas some thought over the week and
> hopefully come up with something good .

How about that:
1) src_install() installs a file, like in:
/var/lib/gentoo/filecaps.d/${PF}
specifying which caps have to applied to which files,

2) the eclass depends on an ebuild, installing a kind
of 'filecaps-apply' tool, reading information from that file and trying
to apply filecaps as necessary (and flipping setuid bits),

3) the eclass calls that tool in pkg_postinst() to apply the caps
on the target filesystem.

This should help with all the issues mentioned, including binpkg
support. Moreover, user could use the tool manually to restore/reset
filecaps if they were lost or unapplied (e.g. due to incorrect kernel
config).

--
Best regards,
Michał Górny
 
Old 03-07-2011, 10:40 AM
Brian Harring
 
Default eclass for handling of file-based capabilities

On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner <constanze@gentoo.org> wrote:
>
> > On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > > * some filesystems don't support xattrs at all, and the package
> > > manager needs to support installing to them, even if the user is
> > > building on a filesystem that does support it
> >
> > While GSoC I was not able to come up with a good fallback mechanism.
> > I'm going to give the new ideas some thought over the week and
> > hopefully come up with something good .
>
> How about that:
> 1) src_install() installs a file, like in:
> /var/lib/gentoo/filecaps.d/${PF}
> specifying which caps have to applied to which files,
>
> 2) the eclass depends on an ebuild, installing a kind
> of 'filecaps-apply' tool, reading information from that file and trying
> to apply filecaps as necessary (and flipping setuid bits),
>
> 3) the eclass calls that tool in pkg_postinst() to apply the caps
> on the target filesystem.

Exactly what benefit is derived from trying to step outside the PM for
this, and trying to hack up what the PM already set for permissions?

General rule of thumb, the more the PM knows the better things are
going to be for people, and for long term compatibility. If
in doubt consider the improvements to user experience via
revdep-rebuild functionality making it into the PM; PM can actually
plan for rebuilds as it goes rather than potentially blowing up a
later build (or telling the user "go run xyz"). Consider:

1) this tool will have to grow system/user configuration for
overrides- something the PM could fold in easily enough into it's
existing capbilities. If in doubt consider FEATURES=suidctl .

2) has to be prefix aware, including understanding of deprived. This
can be done mind you, but like #1, the bits are already there at the
PM level.

3) the information recorded there is ultimately redundant when/if a
sane VDB format gets created; as is this info could just as easily be
pushed in there as a new file per CPV in the existant VDB format.

4) this requires further OOB handling for ID databases- handling that
could've been pushed into the PM itself (admittedly a weak point since
ID is already mildly screwed up here, but no point in making it
worse).

5) it opens up a window in every merge where setuid binaries are on
disk, just prior to your proposed tool getting ran. This is annoying
to say the least, and if the system has disabled setuid in full it's a
window where the binaries aren't actually usable.

6) it's slower than just having the PM do it. Specifically, the PM is
already transfering the content to disk, and fiddling it's bits-
adjusting the files modes and setting capability is something it can
do on creation (eliminating #5) rather than having to shell out to
some script. It's important to realize that the area this slows down
is a critical section for parallelized binpkg merging- something the
chrome-os folk have ran into.

6) shifting it to an external tool means the format used by the tool
needs standardization (rather than just being standardized via PMS) to
allow interop when inevitably a PM author goes to fold the
functionality into the PM.

7) this tool, due to it being not part of the PM, the PM has to go out
of it's way to protect the depgraph for- something it should already
be doing for itself. External, it's another hardcoded constant (or
addition to system set) the PM has to watch for- w/in the pm, it ought
to pay attention to it as is.


> This should help with all the issues mentioned, including binpkg
> support. Moreover, user could use the tool manually to restore/reset
> filecaps if they were lost or unapplied (e.g. due to incorrect kernel
> config).

Every issue you've raised is addressable at the PM level- generally
speaking, done better at the PM level.

Basically... please fix the problem at the correct location.
Capabilities, xattrs, etc, are not a temporary fad- they're
increasingly a core requirement of a linux system (thus the PM that
manages it). The place for this functionality is in the PM- more
importantly, trying to do it outside of it just makes a bigger mess
for PM/format authors when inevtiably it has to be pulled in.

~harring
 

Thread Tools




All times are GMT. The time now is 09:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org