From: Patrick Ohly <patrick.ohly@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: [PATCH 0/3] replace suid with capabilities, for example in busybox
Date: Wed, 9 Dec 2015 20:14:28 +0100 [thread overview]
Message-ID: <cover.1449683756.git.patrick.ohly@intel.com> (raw)
I started working on hardening a distro by replacing suid binaries
with executables that add only the necessary capabilities via file
capabilities. It is understood that this is often still a path
towards privilege escalation (see
https://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c6fbcf62fd5d3472562540a7e608ce4e#p10271)
but as part of a defense-in-depth strategy it's still useful.
I'd like to get the first two patches reviewed and, if seen as useful,
merged into master.
The busybox_%.bbappend is just an example how this would be used. It's
not meant to be merged.
There's currently one caveat: the file capabilities do not get copied
into images. I see them under pseudo (with getcap, filecap and as
security.capability xattr with getfattr), but they do not get copied
into an ext4 image by mkfs.ext4.
Robert, I tried that with the patched e2fsprogs from meta-selinux. Is
that perhaps something you can look into as part of
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8622 ?
Actually, I just noticed another problem with that e2fsprogs version:
with Smack enabled via meta-intel-iot-security/meta-security-smack,
/etc has under pseudo:
# getfattr -d -m . rootfs/etc/
# file: ../rootfs/etc/
security.SMACK64="System::Shared"
security.SMACK64TRANSMUTE="TRUE"
A loop-mounted ext4 image only has one xattr:
security.SMACK64TRANSMUTE="TRUE"
The following changes since commit 192da885e92d3b163b9c4e6b8151c9ecc6062b14:
build-appliance-image: Update to master head revision (2015-12-09 08:49:13 +0000)
are available in the git repository at:
git://github.com/pohly/openembedded-core capabilities
https://github.com/pohly/openembedded-core/tree/capabilities
Patrick Ohly (3):
capabilities.bbclass: add file capabilities automatically
busybox.inc: prepare for additional link files
busybox_%.bbappend: run ping and traceroute with file capabilities
meta/classes/capabilities.bbclass | 58 ++++++++++++++++++++++++++++
meta/recipes-core/busybox/busybox.inc | 16 ++++----
meta/recipes-core/busybox/busybox_%.bbappend | 41 ++++++++++++++++++++
3 files changed, 108 insertions(+), 7 deletions(-)
create mode 100644 meta/classes/capabilities.bbclass
create mode 100644 meta/recipes-core/busybox/busybox_%.bbappend
--
2.1.4
next reply other threads:[~2015-12-09 18:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-09 19:14 Patrick Ohly [this message]
2015-12-09 19:14 ` [PATCH 1/3] capabilities.bbclass: add file capabilities automatically Patrick Ohly
2015-12-09 19:14 ` [PATCH 2/3] busybox.inc: prepare for additional link files Patrick Ohly
2015-12-09 19:14 ` [PATCH 3/3] busybox_%.bbappend: run ping and traceroute with file capabilities Patrick Ohly
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=cover.1449683756.git.patrick.ohly@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.