netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org
Cc: luto@amacapital.net, stephen@networkplumber.org
Subject: Re: [RFC PATCH iproute2] Drop capabilities if not running ip exec vrf with libcap
Date: Tue, 27 Mar 2018 18:05:45 +0100	[thread overview]
Message-ID: <1522170345.14111.110.camel@debian.org> (raw)
In-Reply-To: <4f03183a-3373-62b7-06ea-b1198299c8d5@gmail.com>

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

On Tue, 2018-03-27 at 10:40 -0600, David Ahern wrote:
> On 3/27/18 10:24 AM, Luca Boccassi wrote:
> > ip vrf exec requires root or CAP_NET_ADMIN, CAP_SYS_ADMIN and
> > CAP_DAC_OVERRIDE. It is not possible to run unprivileged commands
> > like
> > ping as non-root or non-cap-enabled due to this requirement.
> > To allow users and administrators to safely add the required
> > capabilities to the binary, drop all capabilities on start if not
> > invoked with "vrf exec".
> > Update the manpage with the requirements.
> > 
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> > 
> > I'd like to be able to run ip vrf exec as a normal user, does this
> > approach
> > sound sensible? Any concerns? Are there any other alternatives?
> > It would be up to each user/admin/whatever to make sure the program
> > is
> > built with libcap and to add the capabilities manually, so nothing
> > will be
> > there by default.
> 
> This is very similar to a change I recently made for our
> distribution. I
> created a separate 'runvrf' command so as to not contaminate 'ip'
> (the
> runvrf command has the limitation it can not configure the VRF cgroup
> so
> that needs to be done before runvrf).

Great, thanks for the feedback!

> > 
> >  configure         | 17 +++++++++++++++++
> >  ip/ip.c           | 34 ++++++++++++++++++++++++++++++++++
> >  man/man8/ip-vrf.8 |  8 ++++++++
> >  3 files changed, 59 insertions(+)
> > 
> > diff --git a/configure b/configure
> > index f7c2d7a7..5ef5cd4c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -336,6 +336,20 @@ EOF
> >      rm -f $TMPDIR/strtest.c $TMPDIR/strtest
> >  }
> >  
> > +check_cap()
> > +{
> > +	if ${PKG_CONFIG} libcap --exists
> > +	then
> > +		echo "HAVE_CAP:=y" >>$CONFIG
> > +		echo "yes"
> > +
> > +		echo 'CFLAGS += -DHAVE_LIBCAP' `${PKG_CONFIG}
> > libcap --cflags` >>$CONFIG
> > +		echo 'LDLIBS +=' `${PKG_CONFIG} libcap --libs` >>
> > $CONFIG
> > +	else
> > +		echo "no"
> > +	fi
> > +}
> > +
> >  quiet_config()
> >  {
> >  	cat <<EOF
> > @@ -410,6 +424,9 @@ check_berkeley_db
> >  echo -n "need for strlcpy: "
> >  check_strlcpy
> >  
> > +echo -n "libcap support: "
> > +check_cap
> > +
> >  echo >> $CONFIG
> >  echo "%.o: %.c" >> $CONFIG
> >  echo '	$(QUIET_CC)$(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c -o $@
> > $<' >> $CONFIG
> > diff --git a/ip/ip.c b/ip/ip.c
> > index e0cd96cb..49739571 100644
> > --- a/ip/ip.c
> > +++ b/ip/ip.c
> > @@ -17,6 +17,10 @@
> >  #include <netinet/in.h>
> >  #include <string.h>
> >  #include <errno.h>
> > +#include <sys/types.h>
> > +#ifdef HAVE_LIBCAP
> > +#include <sys/capability.h>
> > +#endif
> >  
> >  #include "SNAPSHOT.h"
> >  #include "utils.h"
> > @@ -68,6 +72,24 @@ static int do_help(int argc, char **argv)
> >  	return 0;
> >  }
> >  
> > +static void drop_cap(void)
> > +{
> > +#ifdef HAVE_LIBCAP
> > +	/* don't harmstring root/sudo */
> > +	if (getuid() != 0 && geteuid() != 0) {
> > +		cap_t capabilities;
> > +		capabilities = cap_get_proc();
> > +		if (!capabilities)
> > +			exit(EXIT_FAILURE);
> > +		if (cap_clear(capabilities) != 0)
> > +			exit(EXIT_FAILURE);
> > +		if (cap_set_proc(capabilities) != 0)
> > +			exit(EXIT_FAILURE);
> > +		cap_free(capabilities);
> > +	}
> > +#endif
> > +}
> 
> You don't need the capabilities after the cgroup has been changed, so
> you can add a call to drop_cap at the end of vrf_switch.

Ok, if Stephen finds the approach correct I'll send a v1 with that
change (it shouldn't be strictly necessary as execvp which is ran just
after vrf_switch drops caps, but it won't hurt either).

-- 
Kind regards,
Luca Boccassi

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

  reply	other threads:[~2018-03-27 17:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 16:24 [RFC PATCH iproute2] Drop capabilities if not running ip exec vrf with libcap Luca Boccassi
2018-03-27 16:40 ` David Ahern
2018-03-27 17:05   ` Luca Boccassi [this message]
2018-03-27 17:15 ` Stephen Hemminger
2018-03-27 17:43   ` Luca Boccassi
2018-03-27 17:48 ` [PATCH iproute2 v1] " Luca Boccassi
2018-03-27 18:52   ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1522170345.14111.110.camel@debian.org \
    --to=bluca@debian.org \
    --cc=dsahern@gmail.com \
    --cc=luto@amacapital.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).