On Mon, 18 Oct 2010 09:31:32 -0400, Steven Bellovin
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 (:
On Mon, 18 Oct 2010 09:31:32 -0400
Steven Bellovin 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 tim
On Mon, 18 Oct 2010 14:51:03 +0200
Jean-Yves Migeon 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 implementa
On Oct 18, 2010, at 8:51 03AM, Jean-Yves Migeon wrote:
>
> On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon
> 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 wrote:
>>>
2) Finish the asymme
On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon
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 wrote:
>>
>> >2) Finish the asymmetric operation support in cryptodev and
>> > actually require
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 n
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 wrote:
>
> > 2) Finish the asymmetric operation support in cryptodev and
> >actually require modules to be signed. This is basically a
> >superset of #1
On Sat, 16 Oct 2010 13:58:19 -0400
Thor Lancelot Simon 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
On Oct 16, 2010, at 4:49 57PM, John Nemeth wrote:
> 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
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 th
> } > 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
> } co
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,
}
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 r
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 ne
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
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 aut
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
>
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 mo
> > 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 syst
> ...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.
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
On Sat, 16 Oct 2010, David Holland wrote:
On Sat, Oct 16, 2010 at 05:07:30AM -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
> 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.
I have no interest in such discussion either.
I'm asking if options INSECURE is required to use modul
On Sat, Oct 16, 2010 at 05:07:30AM -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 bein
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 prope
> > > > 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 i38
On Sun, 17 Oct 2010 03:38:42 +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
> > > > ju
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 conv
> > > > 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 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
> > 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?
---
Izumi Tsut
On Sun, Oct 17, 2010 at 01:08:05AM +0900, Masao Uebayashi wrote:
>
> 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
b) here sho
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 loa
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 s
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?
} >
} >>
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 bo
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
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 t
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
> 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
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
> 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
> "bl
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.
> > 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
On Sat, Oct 16, 2010 at 12:35:02PM +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 speci
> > Hmm, what do you think about this feature?
> > Only available in INSECURE environment?
>
> I think it makes sense once we have lots of device drivers as modules.
> Boot minimal kernel, autoload all needed device drivers, lock system
> state. At least in configurations where you want to lock it
On Sat, Oct 16, 2010 at 12:35:02PM +0900, Izumi Tsutsui wrote:
> Hmm, what do you think about this feature?
> Only available in INSECURE environment?
I think it makes sense once we have lots of device drivers as modules.
Boot minimal kernel, autoload all needed device drivers, lock system
state. A
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 contai
> > > 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??
>
>
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 nece
> > > 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?
>
>
On Sat, Oct 16, 2010 at 11:11:07AM +0900, Izumi Tsutsui wrote:
> > 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 loade
> 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
53 matches
Mail list logo
