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 --]
next prev parent 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).