6:44 p.m.
Hi all:
This there any interest in the ability to install rpms with a
customization stick? I have a POC patch that does that with just a small
patch to dracut's 30olpc-customization routine[1]. On a side note I
noticed that the use of unzip suffers the same issue as os-builder does
when it comes to registering the activities' mimetype. Think the best
way around this is the same fix as I proposed here[2]. If we have to
chroot into the image for the rpms, think the activities should be
handled the same way.
Feedback very much welcome,
Jerry
[1] https://dev.laptop.org.au/attachments/186/dracut30.diff
[2] http://dev.laptop.org/attachment/ticket/10427/kspost.61.mimelink.inc
7 p.m.
Hi Jerry,
On Wed, May 04 2011, Jerry Vonau wrote:
This there any interest in the ability to install rpms with a
customization stick? I have a POC patch that does that with just a
small patch to dracut's 30olpc-customization routine.
There's interest, but it's more complicated than you think. As I
understand it, customization sticks can be signed and run in secure mode
because they perform no side-effects outside of /home. However, an RPM
can have a %post section which lists commands to be run *as root* during
the installation.
So, offering the ability to install RPMs via signed customization stick
is equivalent to letting anyone run any series of commands as root.
There may be ways to mitigate this risk, such as refusing to run any
%post scripts (some of which are necessary for proper function of
packages). Working out what the safe set of actions a hostile RPM
can perform on a system is a research project, as far as I know.
Thanks,
- Chris.
--
Chris Ball <cjb(a)laptop.org> <http://printf.net/>
One Laptop Per Child
7:12 p.m.
On Wed, 2011-05-04 at 20:00 -0400, Chris Ball wrote:
Hi Jerry,
On Wed, May 04 2011, Jerry Vonau wrote:
> This there any interest in the ability to install rpms with a
> customization stick? I have a POC patch that does that with just a
> small patch to dracut's 30olpc-customization routine.
There's interest, but it's more complicated than you think. As I
understand it, customization sticks can be signed and run in secure mode
because they perform no side-effects outside of /home. However, an RPM
can have a %post section which lists commands to be run *as root* during
the installation.
So, offering the ability to install RPMs via signed customization stick
is equivalent to letting anyone run any series of commands as root.
How is different from using "sudo rpm/yum"? You still have to have trust
in the rpms.
There may be ways to mitigate this risk, such as refusing to run any
%post scripts (some of which are necessary for proper function of
packages). Working out what the safe set of actions a hostile RPM
can perform on a system is a research project, as far as I know.
I'd say just let the deployments sign their own kernel and initrd.img,
OLPC doesn't have to offer the stick for public use.
Jerry
5:14 a.m.
On 05/05/2011 9:58 AM, "Chris Ball" <cjb(a)laptop.org> wrote:
There's interest, but it's more complicated than you think.
As I
understand it, customization sticks can be signed and run in secure mode
because they perform no side-effects outside of /home. However, an RPM
can have a %post section which lists commands to be run *as root* during
the installation.
So, offering the ability to install RPMs via signed customization stick
is equivalent to letting anyone run any series of commands as root.
There may be ways to mitigate this risk, such as refusing to run any
%post scripts (some of which are necessary for proper function of
packages). Working out what the safe set of actions a hostile RPM
can perform on a system is a research project, as far as I know.
Can we make it so that it only installs signed RPMs? Would that help?
Sridhar
8:09 a.m.
On May 10, 2011, at 6:14 AM, Sridhar Dhanapalan wrote:
On 05/05/2011 9:58 AM, "Chris Ball" <cjb(a)laptop.org>
wrote:
> There's interest, but it's more complicated than you think. As I
> understand it, customization sticks can be signed and run in
secure mode
> because they perform no side-effects outside of /home. However,
an RPM
> can have a %post section which lists commands to be run *as root*
during
> the installation.
>
> So, offering the ability to install RPMs via signed customization
stick
> is equivalent to letting anyone run any series of commands as root.
>
> There may be ways to mitigate this risk, such as refusing to run any
> %post scripts (some of which are necessary for proper function of
> packages). Working out what the safe set of actions a hostile RPM
> can perform on a system is a research project, as far as I know.
Can we make it so that it only installs signed RPMs? Would that help?
I signed manifest which includes a list of files would probably be
more feasible as you wouldn't have to alter the RPMs.
Reuben
9:01 a.m.
On 10 May 2011 23:09, Reuben K. Caron <reuben(a)laptop.org> wrote:
On May 10, 2011, at 6:14 AM, Sridhar Dhanapalan wrote:
Can we make it so that it only installs signed RPMs? Would that help?
I signed manifest which includes a list of files would probably be more
feasible as you wouldn't have to alter the RPMs.
Good point.
However, I was thinking along more simplistic lines. We could have
have it so that one can only install RPMs signed with a signature[0]
that is present in the RPM database. This would allow users to add
their own RPMs, but prevent 'unofficial' ones from being installed.
Sridhar
[0] https://fedoraproject.org/keys
2:29 p.m.
Hi,
On Tue, May 10 2011, Sridhar Dhanapalan wrote:
However, I was thinking along more simplistic lines. We could have
have it so that one can only install RPMs signed with a signature[0]
that is present in the RPM database. This would allow users to add
their own RPMs, but prevent 'unofficial' ones from being installed.
I think it's still more complicated than that.
There could be a Fedora-signed RPM -- perhaps a sysadmin tool of some
kind -- that opens up root access to users in some way or another.
(And of course there are many Fedora-signed RPMs that develop known
security vulnerabilities at some point in their lives.)
I don't know if such a signed RPM exists, but my point is that we're
moving the semantics of a customization key from "it's safe to secure-
boot a customization key on a locked machine" to "this greatly increases
the risk vector of secure-booting customization keys".
Anyway, I'm not saying that you shouldn't do it yourselves. But OLPC
would have to be careful before signing a key with your patch included
if there are any locked deployments that use OLPC's keychain, which
means we should use the same care when deciding whether to merge the
patch. Martin and dsd would be better at speaking to how big a worry
this is for deployments in real-world terms.
Thanks,
- Chris.
--
Chris Ball <cjb(a)laptop.org> <http://printf.net/>
One Laptop Per Child
11:46 a.m.
On Tue, May 10, 2011 at 3:29 PM, Chris Ball <cjb(a)laptop.org> wrote:
I think it's still more complicated than that.
Agreed. I would say two things
- Currently rpm-based installations are prone to problems with
powerloss (stay tuned for btrfs, and cjb's work on it...). If you go
this way, and you have a large number of laptops, probabilities turn
into number of real laptops affected. If you accept that, then...
- A secure laptop should only execute or install stuff signed by its
admin team - rpms listed in a manifest signed with its OATS keys for
example. (If you are going to go that route -- signed scripts and
lists of rpms, Puppet is you friend - yes, even for the XOs
themselves.)
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
4741
days inactive
4754
days old
7 comments
5 participants
participants (5)
-
Chris Ball -
Jerry Vonau -
Martin Langhoff -
Reuben K. Caron -
Sridhar Dhanapalan