Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon t...@panix.com wrote: On Sun, Oct 17, 2010 at 04:04:59PM -0400, Matthew Mondor wrote: On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to Let me know when you've got the code ready for review. *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: kernel module loading vs securelevel
On Oct 18, 2010, at 8:51 03AM, Jean-Yves Migeon wrote: On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon t...@panix.com wrote: On Sun, Oct 17, 2010 at 04:04:59PM -0400, Matthew Mondor wrote: On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to Let me know when you've got the code ready for review. *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Signatures provide *authentication*; what is needed here is *authorization*. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 14:51:03 +0200 Jean-Yves Migeon jeanyves.mig...@free.fr wrote: *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Thanks, that's nice to know, I didn't look at netpgp yet but might eventually check if its RSA implementation (if any) can eventually be worked into common/lib/libc/rsa, which would be a major step forward to allow the kernel to verify signatures. I started writing a task list to have an idea of what needs to be done, and it's not trivial (http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/netbsd/signed_modules.txt?rev=1.5;content-type=text%2Fplain). I might give an implementation a try during my next vacations, but no timeline or guarantee (disclaimer!). Motivation is also a factor as my current (very simple) solution to the various MODULAR issues I've faced (mostly maintenance related) has been so far to use monolithic kernels. -- Matt
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 09:31:32 -0400 Steven Bellovin s...@cs.columbia.edu wrote: Signatures provide *authentication*; what is needed here is *authorization*. While I agree, there also are situations were both can be welcome... Another solution someone proposed which I like is hashing the modules to then at load time rehash and match a module against the hash set, which would be a simpler, shorter-term solution. I think that embedding the hashes set in the kernel image would be safer than using a file, however. Unfortunately, this makes developing, installing or upgrading a module less friendly as the kernel image has to be refreshed and the system rebooted. -- Matt
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 09:31:32 -0400, Steven Bellovin s...@cs.columbia.edu wrote: *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Signatures provide *authentication*; what is needed here is *authorization*. And integrity (: -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to care about module location or their mutability; allowing delegation (multiple trusted public keys allow to verify signatures of various trusted third parties), among others. A developer working on a module only has to sign it without any further trouble to test it (assuming he included his public key in the kernel image). No need to go change the flags of a hashes file (a plausible point of failure anyway), update it, make it immutable again, etc. Of course a serious problem would still exist if the kernel's database of trusted keys could be modified. An effort could be made so that these cannot be modified at runtime but only at kernel image build time, requireing a reboot, and those that care can manage to load the kernel image from a read-only source. To simplify things, couldn't X.509 parsing strictly be done by the userland build infrastructure? The list of trusted keys can be stored in a simple binary format as part of the kernel image, and the module signature can also be stored as a simple binary format as part of that module. If you want to be able to revoke an existing key at runtime, support the use of subkeys and CAs and the like, things suddenly become more complex, but I don't think it's necessary for this. Even a simpler system with no trusted entities list could make use of this: a random key pair could be generated at build time, the public part of it the only stored key in the kernel image, and all modules signed with the private part of that key, which then gets discarded... Although the only advantage over veriexec-like hashes in this case would be reduced kernel image read-only data segment (i.e. one 1024-bit public key stored instead of n * 160-bit hashes). -- Matt
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 04:04:59PM -0400, Matthew Mondor wrote: On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to Let me know when you've got the code ready for review. Thor
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
autoload/autounload does NOT perform any authorization checks - please
look at the code! No checking of securelevel occurs, as far as I can
see. For autoload, the module name must not contain a '/', so if the
module is being loaded from the file system it must be loaded from the
blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
INSECURE option will have no effect on autoloading of modules.
Hmm.
I built MODULAR kernels on news68k and sun3 (which didn't have INSECURE)
but I couldn't use TMPFS or execute a.out binaries on multiuser
though they worked after shutdown(8) or on single user.
The code doesn't work as intended and just we should fix it?
Hmmm. Maybe I am reading the code wrong. But the intent of the code
seems to be quite clear. The manual load explicitly calls kauth_...()
while the auto-load path does not make any such call.
Perhaps there is an additional authorization call in kobj_load_vfs()
(which does the actual loading). A quick grep of subr_kobj*.c for
kauth_ does not reveal anything obvious.
Could you rerun your testing after setting sysctl kern.module.verbose?
This should provide extra kernel debug printf() messages...
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
Hmmm. OK, I will build an i386 kernel _without_ INSECURE and see if I can reproduce the problem. On Sat, 16 Oct 2010, Izumi Tsutsui wrote: Could you rerun your testing after setting sysctl kern.module.verbose? This should provide extra kernel debug printf() messages... There are some info during boot (before securelevel is set to 1): --- : Mounting all filesystems... DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/mfs/mfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/kernfs/kernfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/procfs/procfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/ptyfs/ptyfs.kmod' DEBUG: module: cannot unload module `mfs' error=16 DEBUG: module: cannot unload module `kernfs' error=16 DEBUG: module: cannot unload module `procfs' error=16 Clearing temporary files. DEBUG: module: cannot unload module `ptyfs' error=16 Starting amd. Creating a.out runtime link editor directory cache. Checking quotas: done. Setting securelevel: kern.securelevel: 0 - 1 : --- All file systems (mfs, kernfs, procfs, and ptyfs) are mounted properly, though. On multi user, there is no particular info: --- # mount -t tmpfs tmpfs /mnt mount_tmpfs: tmpfs on /mnt: Operation not supported by device # shutdown now Shutdown NOW! : Enter pathname of shell or RETURN for /bin/sh: Terminal type is kterm. We recommend creating a non-root account and using su(1) for root access. # mount -t tmpfs tmpfs /mnt DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/tmpfs/tmpfs.kmod' chariot# df /mnt Filesystem 1K-blocks Used Avail %Cap Mounted on tmpfs 49480 8 49472 0% /mnt # DEBUG: module: cannot unload module `tmpfs' error=16 --- Izumi Tsutsui !DSPAM:4cb9a96b2437545078506! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: kernel module loading vs securelevel
On Jan 31, 5:14pm, Paul Goyette wrote:
} On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
}
} Hmm, what do you think about this feature?
} Only available in INSECURE environment?
}
} We trust modules at the time when they're installed into the trusted
} place, same as kernel itself. I think prohibiting module load at
} run-time is rather pointless.
}
} Well I think the point is whether we should require INSECURE or not
} to use module autoload/autounload after multiuser.
}
} If we should I'll enable options INSECURE by default on ports
} that require options MODULAR (to save kernel file size).
}
} autoload/autounload does NOT perform any authorization checks - please
} look at the code! No checking of securelevel occurs, as far as I can
I just did and autoload most certainly does do authorization
checks.
} see. For autoload, the module name must not contain a '/', so if the
} module is being loaded from the file system it must be loaded from the
} blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
} INSECURE option will have no effect on autoloading of modules.
}
} Manual loading and unloading of modules does involve calls to
} kauth_authorize_system() which will check securelevel.
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
}-- End of excerpt from Paul Goyette
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010, John Nemeth wrote:
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
Hmmm, missed that one. You're right.
The arg is, I think, the one that gets passsed to the kauth listener as
arg2, which should cause us to return KAUTH_RESULT_ALLOW for autoload:
static int
module_listener_cb(kauth_cred_t cred, kauth_action_t action, void *cookie,
void *arg0, void *arg1, void *arg2, void *arg3)
{
int result;
result = KAUTH_RESULT_DEFER;
if (action != KAUTH_SYSTEM_MODULE)
return result;
if ((uintptr_t)arg2 != 0) /* autoload */
result = KAUTH_RESULT_ALLOW;
return result;
}
}-- End of excerpt from Paul Goyette
!DSPAM:4cb9cb6e2431088414278!
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010, Masao Uebayashi wrote:
On Sat, Oct 16, 2010 at 08:57:04AM -0700, John Nemeth wrote:
On Jan 31, 5:14pm, Paul Goyette wrote:
} On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
}
} Hmm, what do you think about this feature?
} Only available in INSECURE environment?
}
} We trust modules at the time when they're installed into the trusted
} place, same as kernel itself. I think prohibiting module load at
} run-time is rather pointless.
}
} Well I think the point is whether we should require INSECURE or not
} to use module autoload/autounload after multiuser.
}
} If we should I'll enable options INSECURE by default on ports
} that require options MODULAR (to save kernel file size).
}
} autoload/autounload does NOT perform any authorization checks - please
} look at the code! No checking of securelevel occurs, as far as I can
I just did and autoload most certainly does do authorization
checks.
} see. For autoload, the module name must not contain a '/', so if the
} module is being loaded from the file system it must be loaded from the
} blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
} INSECURE option will have no effect on autoloading of modules.
}
} Manual loading and unloading of modules does involve calls to
} kauth_authorize_system() which will check securelevel.
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
I read it as:
a) module_listener_cb() checks the 2nd arg, if autoload, judge the auth
as allow
b) secmodel_securelevel_system_cb() denies the auth if (securelevel
0) regardless of autoload
Kauth disallows the auth, because 0 listner(s) denied.
Ah, I see. That definitely explains it.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:40:21PM +0900, Masao Uebayashi wrote: We trust modules at the time when they're installed into the trusted place, same as kernel itself. I think prohibiting module load at run-time is rather pointless. The trusted place? What's that? Except in the single special case of autoload, the trusted place could be anywhere on the filesystem, or on any remote filesystem for that matter. If you want to enforce the rule any trusted module can be loaded but only trusted modules can be loaded, while preserving the securelevel framework, the obvious options are: 1) Load module hashes into the kernel at compile or boot time, like veriexec does, 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. Thor
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:53:52PM +0900, Izumi Tsutsui wrote: Hmm, what do you think about this feature? Only available in INSECURE environment? We trust modules at the time when they're installed into the trusted place, same as kernel itself. I think prohibiting module load at run-time is rather pointless. Well I think the point is whether we should require INSECURE or not to use module autoload/autounload after multiuser. If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Thor
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 03:03:58AM +0900, Izumi Tsutsui wrote: If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Heh, then why have we had it on i386 for years? So what you're trying to suggest is that if one port, for historical reasons, ships with an insecure setting in the default kernel, that's an explanation of why *every* port should? I think there's something wrong with your logic. Thor
Re: kernel module loading vs securelevel
If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Heh, then why have we had it on i386 for years? So what you're trying to suggest is that if one port, for historical reasons, ships with an insecure setting in the default kernel, that's an explanation of why *every* port should? Who said *every* port? If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 03:38:42AM +0900, Izumi Tsutsui wrote: Heh, then why have we had it on i386 for years? Because of the X server. You are just saying: We introduced a significant security regression just for our own convenience. Perhaps... I see no proper reason to avoid INSECURE for MODULAR if it's okay for X. ...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. This gets back to the underlying question of what purpose modules are supposed to serve, and as I know everyone knows what I think and is sick and tired of hearing about it, I'll pipe down. -- David A. Holland dholl...@netbsd.org
re: kernel module loading vs securelevel
...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. actually, with DRM (and KMS) i believe we will be able to run the X server as non-root. .mrg.
Re: kernel module loading vs securelevel
I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. No. As far as I can tell, there's a bug in the relevant kauth listener, at least in terms of the original intent of the author of the autoloading code; the system scope kauth listener should return DEFER, not DENY. Okay, fair enough. Thanks. However, I think it's a troublesome question whether this is really the right policy to apply. : Well, it's another discussion how modules can be secure, which is out of my scope. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 12:03:52PM -0700, Paul Goyette wrote:
autoload/autounload does NOT perform any authorization checks -
please look at the code! No checking of securelevel occurs, as far
as I can see. For autoload, the module name must not contain a
'/', so if the module is being loaded from the file system it must
be loaded from the blessed /stand/${ARCH}/${VERSION}/modules
directory. Including the INSECURE option will have no effect on
autoloading of modules.
If this is true it makes securelevel useless; all you need to do is
put a hostile module in the right place and cause it to be autoloaded.
(Remember the point of securelevel is that even root can't lower it.)
John Nemeth has already pointed out that my reading of the code was
flawed. Module autoloading _does_ call kauth for authorization.
The kauth listener provided by the module subsystem returns ALLOW
for all autoload calls, but this gets overridden by another kauth
listener, so autoload still gets denied.
Good that it's not true then :-)
It should be sufficient, I think, to check at boot time that any
module that can be autoloaded is marked immutable.
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.
--
David A. Holland
dholl...@netbsd.org
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 06:13:11AM +1100, matthew green wrote: ...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. actually, with DRM (and KMS) i believe we will be able to run the X server as non-root. Yes, after what, some fifteen years? :-/ -- David A. Holland dholl...@netbsd.org
Re: kernel module loading vs securelevel
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. BTW, does the immutable flag prevent one from using an immutable directory as the mount-point for some other file system? Hmmm... - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: kernel module loading vs securelevel
Hi Thor. On Sat, Oct 16, 2010 at 03:08:45PM -0400, Thor Lancelot Simon wrote: On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote: I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. No. As far as I can tell, there's a bug in the relevant kauth listener, at least in terms of the original intent of the author of the autoloading code; the system scope kauth listener should return DEFER, not DENY. However, I think it's a troublesome question whether this is really the right policy to apply. Unless the directory from which modules are loaded is required to be immutable (flags schg) at boot time, this really does introduce a major security regression: now it is possible to override the whole security policy by placing a new kernel module in the existing directory, when the system is running at securelevel 0. I may be missing your point but there are other ways of sabotaging the securelvel mechanism without kernel modules available. It doesn't seem like a new problem to me. A more obvious way to be mischievous for sure but not new. I really only see two ways to keep the convenient behavior you and I both seem to want (autoload of modules when filesystems, syscalls, etc. are used) and the safe behavior I and others building (for example) embedded systems with tight security policies want: either we need to rely on the existing securelevel machinery and require that the directory from which autoload occurs is immutable at kernel boot time (elsewise disabling autoload), or we need to use something like veriexec, when we're still at securelevel 0, to ensure that the modules placed there don't change in any way. Someone is going to ask me why do you want modules at all on a system with a tight security policy? The answer, unfortunately, is licensing, and in particular CDDL code. You can load it into your kernel without pulling the entire kernel sources under CDDL but you cannot link it into your kernel at compile time. :-/
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:28:42PM +, Andrew Doran wrote: I may be missing your point but there are other ways of sabotaging the securelvel mechanism without kernel modules available. It doesn't seem like a new problem to me. A more obvious way to be mischievous for sure but not new. Generally speaking, the other ways require a reboot. So this is worse in what seems to me a relevant way. I'm starting to think the simplest thing -- though it is not so simple! -- that lets people building systems where securelevel actually is used to protect a TCB continue to do so, yet use kernel modules, is to record which modules may be autoloaded at boot time, whether by content hash or dev/ino (with the immutable requirement to ensure reuse does not screw us up). The latter seems like it _should_ be simpler but I bet in practice the former really is. Thor
Re: kernel module loading vs securelevel
On Mar 8, 9:44am, Thor Lancelot Simon wrote: } On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote: } } I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. } However, I think it's a troublesome question whether this is really } the right policy to apply. Unless the directory from which modules are } loaded is required to be immutable (flags schg) at boot time, this really } does introduce a major security regression: now it is possible to override } the whole security policy by placing a new kernel module in the existing } directory, when the system is running at securelevel 0. } } I really only see two ways to keep the convenient behavior you and I both } seem to want (autoload of modules when filesystems, syscalls, etc. are } used) and the safe behavior I and others building (for example) embedded } systems with tight security policies want: either we need to rely on } the existing securelevel machinery and require that the directory from } which autoload occurs is immutable at kernel boot time (elsewise disabling } autoload), or we need to use something like veriexec, when we're still at } securelevel 0, to ensure that the modules placed there don't change in } any way. I would have to agree. Having modules loaded at securelevel 0 when you can't be absolutely sure of what's in them, completely defeats the purpose of running at securelevel 0. }-- End of excerpt from Thor Lancelot Simon
Re: kernel module loading vs securelevel
On Feb 1, 1:25am, 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. No, there isn't. If the module is in the appropriate directory, it can be loaded. }-- End of excerpt from Paul Goyette
Re: kernel module loading vs securelevel
} I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. The following patch makes autoload works even on securelevel 0, but I'm not sure if it's correct and acceptable. If not, options INSECURE is the only way to enable it.. Index: secmodel/securelevel/secmodel_securelevel.c === RCS file: /cvsroot/src/sys/secmodel/securelevel/secmodel_securelevel.c,v retrieving revision 1.20 diff -u -p -r1.20 secmodel_securelevel.c --- secmodel/securelevel/secmodel_securelevel.c 7 Oct 2009 01:06:57 - 1.20 +++ secmodel/securelevel/secmodel_securelevel.c 16 Oct 2010 22:15:11 - @@ -254,7 +254,7 @@ secmodel_securelevel_system_cb(kauth_cre break; case KAUTH_SYSTEM_MODULE: - if (securelevel 0) + if ((uintptr_t)arg2 == 0 securelevel 0) result = KAUTH_RESULT_DENY; break; --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010, Izumi Tsutsui wrote: } I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. The following patch makes autoload works even on securelevel 0, but I'm not sure if it's correct and acceptable. If not, options INSECURE is the only way to enable it.. Based on the discussion regarding the numerous ways in which this could be abused, I would personally vote for requiring INSECURE. At least that way, things are pretty clear. If the proposed patch were used, then you would have only options MODULAR in the kernel config file, which is not at all clear about the security of the resulting kernel. Index: secmodel/securelevel/secmodel_securelevel.c === RCS file: /cvsroot/src/sys/secmodel/securelevel/secmodel_securelevel.c,v retrieving revision 1.20 diff -u -p -r1.20 secmodel_securelevel.c --- secmodel/securelevel/secmodel_securelevel.c 7 Oct 2009 01:06:57 - 1.20 +++ secmodel/securelevel/secmodel_securelevel.c 16 Oct 2010 22:15:11 - @@ -254,7 +254,7 @@ secmodel_securelevel_system_cb(kauth_cre break; case KAUTH_SYSTEM_MODULE: - if (securelevel 0) + if ((uintptr_t)arg2 == 0 securelevel 0) result = KAUTH_RESULT_DENY; break; --- Izumi Tsutsui !DSPAM:4cba24f22438312397761! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
kernel module loading vs securelevel
Log Message: Make common kernel module binaries work on both sun3 and sun3x. Tested on 3/160 (on TME) and (real) 3/80. XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? --- Izumi Tsutsui
Re: kernel module loading vs securelevel
XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 11:23:29AM +0900, Izumi Tsutsui wrote: It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? Yes. Otherwise it's quite easy to defeat securelevel by causing the loading of a module that resets it to -1. -- David A. Holland dholl...@netbsd.org
Re: kernel module loading vs securelevel
It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? Yes. Otherwise it's quite easy to defeat securelevel by causing the loading of a module that resets it to -1. Hmm, what do you think about this feature? Only available in INSECURE environment? Working file: kern_module.c revision 1.26 date: 2008/11/14 23:06:45; author: ad; state: Exp; lines: +85 -3 - If the system encounters a severe memory shortage, start unloading unused kernel modules. - Try to unload any autoloaded kernel modules 10 seconds after their load was successful. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
If I remember correctly, autoload bypasses the authorization calls within the module subsystem. Autoload also works ONLY for modules that are either built-in, passed by the bootloader, or located in the official directory; autoloading from the filesystem is prohibited if the pathname contains any '/'. On Sat, 16 Oct 2010, Izumi Tsutsui wrote: XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? --- Izumi Tsutsui !DSPAM:4cb91b7e2433872420069! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
