including python in the initramfs

including python in the initramfs

[Daniel Drake]

Hi,

OLPC have a security client that runs pre-root-mount in the initramfs
which is quite complex. It is written in Python. As such, we need python
in the initramfs.

What's the best way to include python in a dracut initramfs?

One idea: we could create a separate module which installs all the files
identified by "rpm -q --filesbypkg python". But that's obviously not
distro-portable. It could work for us but I'd prefer that we're able to
share the work we're doing with others. Any other ideas?

Thanks,
Daniel


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Victor Lowther]

On Jun 16, 2009, at 12:40 PM, Daniel Drake <dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org> wrote:

> Hi,
>
> OLPC have a security client that runs pre-root-mount in the initramfs
> which is quite complex. It is written in Python. As such, we need  
> python
> in the initramfs.

/me boggles.

Why can't it run after switching to the real root?

> What's the best way to include python in a dracut initramfs?

Don't if it is at all possible to avoid it. Maintaining such a thing  
will be a nightmare, especially if you want cross distro capability.

> One idea: we could create a separate module which installs all the  
> files
> identified by "rpm -q --filesbypkg python". But that's obviously not
> distro-portable. It could work for us but I'd prefer that we're able  
> to
> share the work we're doing with others. Any other ideas?

Split out the parts that have to run on the initramfs, and rewrite  
them in sh or C.

>
> Thanks,
> Daniel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs"  
> in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Daniel Drake]

On Tue, 2009-06-16 at 13:22 -0500, Victor Lowther wrote:
> > OLPC have a security client that runs pre-root-mount in the initramfs
> > which is quite complex. It is written in Python. As such, we need  
> > python
> > in the initramfs.
> 
> /me boggles.
> 
> Why can't it run after switching to the real root?

heh.. here we go :)

It's part of an antitheft system.
The users of the machine have root access by design, so they could
trivially disable any security system that runs on the root filesystem.
Thieves included.

However, our initramfs is secure. It's signed with OLPC's master key.
Our special BIOS will not boot an unsigned initramfs. So effectively, we
can trust that the code we put in the initramfs cannot be
modified/crippled/disabled.

It's certainly a strange requirement and I figure from your responses
there is no obvious "good" answer. I agree. I just thought I'd ask
anyway.

cheers,
Daniel


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Warren Togami]

On 06/16/2009 02:49 PM, Daniel Drake wrote:
>
> heh.. here we go :)
>
> It's part of an antitheft system.
> The users of the machine have root access by design, so they could
> trivially disable any security system that runs on the root filesystem.
> Thieves included.
>
> However, our initramfs is secure. It's signed with OLPC's master key.
> Our special BIOS will not boot an unsigned initramfs. So effectively, we
> can trust that the code we put in the initramfs cannot be
> modified/crippled/disabled.
>
> It's certainly a strange requirement and I figure from your responses
> there is no obvious "good" answer. I agree. I just thought I'd ask
> anyway.

This is a good case for the modules.d design of dracut.  Write your own 
module that does whatever you want, and install that module only in 
cases where you generate the initrd for your XO.  Your special module 
does not belong in dracut upstream.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Seewer Philippe]

Warren Togami wrote:
[snip]
> This is a good case for the modules.d design of dracut.  Write your own 
> module that does whatever you want, and install that module only in 
> cases where you generate the initrd for your XO.  Your special module 
> does not belong in dracut upstream.

I agree. That's what the module system is designed for among other 
things. Have a look at README.modules and the currently available 
modules, that should give you an idea on how to proceed.

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Daniel Drake]

On Wed, 2009-06-17 at 09:06 +0200, Seewer Philippe wrote:
> Warren Togami wrote:
> [snip]
> > This is a good case for the modules.d design of dracut.  Write your own 
> > module that does whatever you want, and install that module only in 
> > cases where you generate the initrd for your XO.  Your special module 
> > does not belong in dracut upstream.
> 
> I agree. That's what the module system is designed for among other 
> things. Have a look at README.modules and the currently available 
> modules, that should give you an idea on how to proceed.

Yes, thanks. The module system is excellent and I've already been
crafting my work as a module. Dracut is perfect in this respect.

I was just interested in the opportunity of getting some or all of our
work upstream, hence "doing it right" from the start. But I guess we're
still a bit too nutty for that. (whatever you do, don't ask about our
previous initramfs setup!)

Daniel


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: including python in the initramfs

[Warren Togami]

On 06/16/2009 01:40 PM, Daniel Drake wrote:
> One idea: we could create a separate module which installs all the files
> identified by "rpm -q --filesbypkg python". But that's obviously not
> distro-portable. It could work for us but I'd prefer that we're able to
> share the work we're doing with others. Any other ideas?

Aside from the other reasons this is a bad idea, you cannot safely do 
rpm queries for this if you intend on the initrd to ever be built from 
an rpm scriptlet like %post.  The rpmdb locking will cause problems.

Is it really not possible to run the security client after initrd?

What does the security client do?

Warren


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html