LLVM Image Activator

[Charles DeBardeleben]

Just adding my $0.02 to the architectural concept of the use of
magic numbers. I believe that the whole concept if using any form
of the data content of a file to decide what should should interpret
the data is flawed. I believe that this information is properly stored
as meta-data of the file, which for UNIX would probably most naturally
be part of the inode. I think that main reason we rely on "magic" for
this is an over reaction of original UNIX authors to not having been
granted permission to set this part of meta-data in their past.

Now, given the long history of using magic numbers this way, I doubt
that they will go away. However, there currently is still very little
use of magic numbers in the base kernel. I have to wonder if it may
be a better idea to think about a general mechanism to have the
meta-data of a file have an explicit "interpreter" or perhaps even
a more general "access method" vector rather than begin the process
of importing libmagic into the kernel.

-Charles

On Mon, 2013-01-14 at 12:56 -0600, Brooks Davis wrote:
> On Sun, Jan 13, 2013 at 12:24:35PM -0800, John-Mark Gurney wrote:
> > Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800:
> > > On 01/13/13 09:13, Konstantin Belousov wrote:
> > > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote:
> > > >> On 01/13/13 05:20, Konstantin Belousov wrote:
> > > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote:
> > > >>>> Hi Kostik,
> > > >>>>
> > > >>>> 2013/1/7 Konstantin Belousov <kostikbel at gmail.com>:
> > > >>>>> I still do remember the buzz about the binary format 0xCAFEBABE, which
> > > >>>>> AFAIR gained image activator support on several OSes, to be garbage
> > > >>>>> collected.
> > > >>>>
> > > >>>> Maybe it would then be a good idea then to add some kind of general
> > > >>>> purpose remapping imgact? Example:
> > > >>>>
> > > >>>> /etc/imgacttab:
> > > >>>>
> > > >>>> cafebabe /usr/local/bin/java
> > > >>>> cffaedfe /usr/local/bin/osx_emulator
> > > >>>> 4243c0de /usr/bin/lli
> > > >>>>
> > > >>>> That way we still give people the freedom to play around with mapping
> > > >>>> their own executable formats, but don't need to maintain a bunch of
> > > >>>> imgacts.
> > > >>>
> > > >>> A generic module that could be somewhat customized at runtime to map
> > > >>> offset+signature into the shebang path could be a possibility indeed.
> > > >>> I strongly prefer to have it as module and not enabled by default.
> > > >>>
> > > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in
> > > >>> the response to the 50-lines hack.
> > > >>>
> > > >>
> > > >> I think this is a good idea, since it both prevents a profusion of
> > > >> similar activators and works nicely in jails and similar environments. I
> > > >> probably won't write it quickly, but it should not take more than about
> > > >> 50 lines, so I can't imagine it will be that bad. There are some
> > > >> complications with this kind of design from the things in the XXX
> > > >> comment in imgact_llvm.c about handling argv[0] that I need to think
> > > >> some more about.
> > > > Great. I do not believe in the 50 lines, but I am happy that you want
> > > > to work this out.
> > > > 
> > > >>
> > > >> Why are you opposed to having it there by default? I think it's actually
> > > >> quite important that it be there by default. Having it not "standard"
> > > >> would be fine, but it should at least be in GENERIC. There are minimal
> > > >> security risks since it just munges begin_argv and doesn't even load the
> > > >> executable and it's little enough code that there should not be any
> > > >> kernel bloat to speak of. If things like this aren't enabled by default,
> > > >> no one can depend on them being there, no one will use it, and the point
> > > >> is entirely lost.
> > > > All image activators demonstrated a constant stream of security holes.
> > > > Even our ELF activator, and I was guilty there too.
> > > > 
> > > > I definitely do not fight over the inclusion of the proposed activator
> > > > into GENERIC, but do insist on the config option + module.
> > > > 
> > > 
> > > OK, that sounds like a plan then. I'll try to code up something
> > > configurable in the next couple weeks, unless someone else beats me to it.
> > 
> > I'll point out that file already has the magic (pun intended) that we
> > are looking for, though I do realize that the code might be a bit much
> > to import..
> 
> As someone who recently stuffed libmagic into a very constrained sandbox
> environment, I can safely assert that you don't want to go there.  The
> code isn't written in a way that would make this easy and I definitely
> wouldn't want it in the kernel.
> 
> -- Brooks