tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

How to make module autoloading play nice with securelevel

On Sat, Oct 16, 2010 at 01:17:47PM -0700, Paul Goyette wrote:
> On Sat, 16 Oct 2010, David Holland wrote:
>> > And also make the "blessed" directory itself immutable?  :)
>> As I recall the semantics of immutable are such that this isn't
>> necessary to protect modules that are present at boot time (that is,
>> they can't be unlinked/renamed/etc.), and if there are autoloadable
>> modules whose names aren't present at boot time, they'll fail the
>> check.
> I've already misread the code here once, but...
> As far as I can tell, each time a module_autoload call is made, if the  
> module is neither built-in nor passed in by the boot loader, the code  
> will attempt to load it via a call to kobj_load_vfs() which has path as  
> an argument.  It doesn't appear to me that there is any pre-approved  
> list of acceptable objects that can be loaded from the file system.

Right, it's looked up by path.  And this is a problem: you need to make
sure all directories from which modules can be loaded are immutable at
boot time, which is harder than you'd think because it's not just one
directory!  If it were a flat directory of files, it'd be a lot easier.

And then there's the mount-on-top issue.  Jared had a very elegant
suggestion for this: record which device the module autoload root
directory is mounted on at boot time.  At autoload time, check that
the module you're about to load does in fact come from that same device.

I wish I could think of some similarly elegant solution to the "have to
mark everything from the module root down to the modules themselves
immutable -- and check it before enabling autoloading, at boot time"
issue.  But I can't see a way that doesn't require building the whole
hierarchy of autoload-eligible files at boot time.  Can you?

> BTW, does the immutable flag prevent one from using an immutable  
> directory as the mount-point for some other file system?  Hmmm...

I think it's an interesting question whether it should.  I'd tend towards
"yes, it should" but the answer right now is "no, it does not".

This is all useful and important functionality.  We should get it all
working together and try to keep it that way.  I cannot lose the feeling
that there's a non-Baroque solution lurking out there that we just haven't
quite landed on yet.


Home | Main Index | Thread Index | Old Index