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 > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-13-2011, 06:56 PM
Sebastian Harl
 
Default Setting file capabilites of files shipped in binary packages

Hi,

the new upstream version of one of my packages tries to set the
CAP_NET_RAW (permission to use RAW and PACKET sockets) file capability
during "make install" (using setcap(8)). (The affected tool sends ICMP
ECHO_REQUESTS ("pings"), thus needs to open a RAW socket. Imho, setting
the file capability is a nicer approach than setting the setuid bit.)

Now, the question is: is it allowed to ship files having special
capabilities set. I couldn't find anything neither in the policy nor in
the devref. If the answer to that is "yes", how should the package
handle that? Using setcap(8) requires root privileges, so it cannot be
used in debian/rules. Would it be fine to do that in postinst?

TIA for any comments or pointers!

Cheers,
Sebastian

--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
 
Old 03-13-2011, 07:24 PM
Emilio Pozuelo Monfort
 
Default Setting file capabilites of files shipped in binary packages

On 13/03/11 19:56, Sebastian Harl wrote:
> Hi,
>
> the new upstream version of one of my packages tries to set the
> CAP_NET_RAW (permission to use RAW and PACKET sockets) file capability
> during "make install" (using setcap(8)). (The affected tool sends ICMP
> ECHO_REQUESTS ("pings"), thus needs to open a RAW socket. Imho, setting
> the file capability is a nicer approach than setting the setuid bit.)
>
> Now, the question is: is it allowed to ship files having special
> capabilities set. I couldn't find anything neither in the policy nor in
> the devref. If the answer to that is "yes", how should the package
> handle that? Using setcap(8) requires root privileges, so it cannot be
> used in debian/rules. Would it be fine to do that in postinst?

That's exactly what gnome-keyring from experimental does (for CAP_IPC_LOCK). You
can have a look at its postinst.

Cheers,
Emilio


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D7D27F0.7090202@debian.org">http://lists.debian.org/4D7D27F0.7090202@debian.org
 
Old 03-13-2011, 07:37 PM
Ben Hutchings
 
Default Setting file capabilites of files shipped in binary packages

On Sun, 2011-03-13 at 20:56 +0100, Sebastian Harl wrote:
> Hi,
>
> the new upstream version of one of my packages tries to set the
> CAP_NET_RAW (permission to use RAW and PACKET sockets) file capability
> during "make install" (using setcap(8)). (The affected tool sends ICMP
> ECHO_REQUESTS ("pings"), thus needs to open a RAW socket. Imho, setting
> the file capability is a nicer approach than setting the setuid bit.)

This might be a little premature, as the version of 'ls' in unstable
doesn't yet indicate files with setcap flags. Also, what if the program
is installed on a filesystem that doesn't support setcap?

> Now, the question is: is it allowed to ship files having special
> capabilities set. I couldn't find anything neither in the policy nor in
> the devref. If the answer to that is "yes", how should the package
> handle that? Using setcap(8) requires root privileges, so it cannot be
> used in debian/rules.

So do many things involving in building a package, which is why we have
fakeroot. But more importantly:

- fakeroot doesn't yet wrap capset(2)
- tar (which is used by dpkg) doesn't save or restore setcap flags

> Would it be fine to do that in postinst?

It must be done in postinst, and you may need to fall back to setuid if
the filesystem does not support setcap.

Ben.

> TIA for any comments or pointers!
>
> Cheers,
> Sebastian
>

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 03-14-2011, 04:40 AM
Andrey Rahmatullin
 
Default Setting file capabilites of files shipped in binary packages

On Sun, Mar 13, 2011 at 08:24:16PM +0000, Emilio Pozuelo Monfort wrote:
> That's exactly what gnome-keyring from experimental does (for CAP_IPC_LOCK). You
> can have a look at its postinst.
wireshark-common also does that since 2010.

--
WBR, wRAR
 
Old 03-14-2011, 07:17 AM
Sebastian Harl
 
Default Setting file capabilites of files shipped in binary packages

Hi,

On Sun, Mar 13, 2011 at 08:37:53PM +0000, Ben Hutchings wrote:
> On Sun, 2011-03-13 at 20:56 +0100, Sebastian Harl wrote:
> > the new upstream version of one of my packages tries to set the
> > CAP_NET_RAW (permission to use RAW and PACKET sockets) file capability
> > during "make install" (using setcap(8)). (The affected tool sends ICMP
> > ECHO_REQUESTS ("pings"), thus needs to open a RAW socket. Imho, setting
> > the file capability is a nicer approach than setting the setuid bit.)
>
> This might be a little premature, as the version of 'ls' in unstable
> doesn't yet indicate files with setcap flags.

Good point.

> Also, what if the program is installed on a filesystem that doesn't
> support setcap?

Falling back to setuid (as mentioned below) would be a valid option imho
(also, that's the approach currently used).

> > Now, the question is: is it allowed to ship files having special
> > capabilities set. I couldn't find anything neither in the policy nor in
> > the devref. If the answer to that is "yes", how should the package
> > handle that? Using setcap(8) requires root privileges, so it cannot be
> > used in debian/rules.
>
> So do many things involving in building a package, which is why we have
> fakeroot. But more importantly:
>
> - fakeroot doesn't yet wrap capset(2)
> - tar (which is used by dpkg) doesn't save or restore setcap flags

Good points as well :-)

> > Would it be fine to do that in postinst?
>
> It must be done in postinst, and you may need to fall back to setuid if
> the filesystem does not support setcap.

Do you know of a way to find out if the filesystem supports setcap
(other than trying out ;-))?

Thanks for your feedback!

Cheers,
Sebastian

--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
 
Old 03-14-2011, 12:17 PM
Ben Hutchings
 
Default Setting file capabilites of files shipped in binary packages

On Mon, 2011-03-14 at 09:17 +0100, Sebastian Harl wrote:
[...]
> > > Would it be fine to do that in postinst?
> >
> > It must be done in postinst, and you may need to fall back to setuid if
> > the filesystem does not support setcap.
>
> Do you know of a way to find out if the filesystem supports setcap
> (other than trying out ;-))?

No, I don't think there's a way to do that programmatically. You would
just have to try capset and then chmod u+s.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 03-14-2011, 12:43 PM
Timo Juhani Lindfors
 
Default Setting file capabilites of files shipped in binary packages

Sebastian Harl <tokkee@debian.org> writes:
> Imho, setting the file capability is a nicer approach than setting the
> setuid bit.

Do you know about any lurking bugs (in udev, dbus, etc?) that could
allow one to escalate CAP_NET_RAW to full root privileges in regular
squeeze installations?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 84sjupu8ag.fsf@sauna.l.org">http://lists.debian.org/84sjupu8ag.fsf@sauna.l.org
 
Old 03-14-2011, 12:56 PM
Olaf van der Spek
 
Default Setting file capabilites of files shipped in binary packages

On Mon, Mar 14, 2011 at 2:17 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2011-03-14 at 09:17 +0100, Sebastian Harl wrote:
> [...]
>> > > Would it be fine to do that in postinst?
>> >
>> > It must be done in postinst, and you may need to fall back to setuid if
>> > the filesystem does not support setcap.
>>
>> Do you know of a way to find out if the filesystem supports setcap
>> (other than trying out ;-))?
>
> No, I don't think there's a way to do that programmatically. *You would
> just have to try capset and then chmod u+s.

Shouldn't this be done via DH instead of duplicating this code into
lots of postinsts?


--
Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=GnudGc6Cvqn4Hvg2my9ZRVRN2ytMVLOBE+7r6@mail .gmail.com">http://lists.debian.org/AANLkTi=GnudGc6Cvqn4Hvg2my9ZRVRN2ytMVLOBE+7r6@mail .gmail.com
 
Old 03-14-2011, 01:36 PM
sean finney
 
Default Setting file capabilites of files shipped in binary packages

On Mon, Mar 14, 2011 at 01:17:02PM +0000, Ben Hutchings wrote:
> No, I don't think there's a way to do that programmatically. You would
> just have to try capset and then chmod u+s.

instead of chmod, you would actually want something that checked/respected
dpkg-statoverride, rather than hard-coding the permissions. there
unfortunately is no equivalent for capabilities that i know of.

I'd say this would be something that would be best handled either by
extending dpkg-statoverride, or dpkg itself (i.e. declaritive style),
though in the meantime trying to set the capabilities and failing
gracefully in the case that it's not supported seems reasonable.

On Mon, Mar 14, 2011 at 02:56:25PM +0100, Olaf van der Spek wrote:
> Shouldn't this be done via DH instead of duplicating this code into
> lots of postinsts?

Eventually, sure, but no reason to jump the gun while $this is still
rather undefined.


sean


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110314143655.GA5951@cobija.connexer.com">http://lists.debian.org/20110314143655.GA5951@cobija.connexer.com
 

Thread Tools




All times are GMT. The time now is 03:43 AM.

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