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
On Sat, Oct 16, 2010 at 03:22:52PM +0300, Jukka Ruohonen wrote:
> On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote:
> > The main difference that I understood seems to be what you call virtual
> > and natural device trees: in OF world we guide the whole autoconfig tree
> > along the O
> } > 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, 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
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
On Sat, 16 Oct 2010, Jukka Ruohonen wrote:
> On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote:
> > The main difference that I understood seems to be what you call virtual
> > and natural device trees: in OF world we guide the whole autoconfig tree
> > along the OF device tree, with
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
On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote:
> The main difference that I understood seems to be what you call virtual
> and natural device trees: in OF world we guide the whole autoconfig tree
> along the OF device tree, with differences close to the leafs (i.e. the
> scsibus d
> 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
On Sat, Oct 16, 2010 at 11:28:33AM +0300, Jukka Ruohonen wrote:
> I do not know OF well, but my impression is that it is much, much less
> invasive than what we have nowadays on x86 where close interaction between
> the firmware and drivers are expected.
Indeed. Quentin once tried to explain to me
On Fri, Oct 15, 2010 at 08:29:57AM -0400, der Mouse wrote:
> ACPI may be the source of the information, but that doesn't mean it has
> to be how the autoconf tree is constructed.
>
> Compare and contrast with how NetBSD/sparc uses the OF (or is it OBP?
> I'm not sure) device tree to drive autoconf
On Fri, Oct 15, 2010 at 07:53:53PM -0500, David Young wrote:
> > > OK, what this code is doing is essentially attach a device to the acpi
> > tree that really refers to a PCI device. Can we please get this to
> > attach as child of vga0 by checking for a device matching the PCI
> > address of vga0,
46 matches
Mail list logo
