On Thu, 3 Mar 2005 22:25:37 -1000, William Bierman <[EMAIL PROTECTED]> wrote:
> Hello. I have been endeavoring to create my own livecd which will
> mount a remote share from which to run scripts installing a ghost
> image onto a local hard drive. I realize this may be more trouble
> than it's wor
Apparently, On Wed, Dec 19, 2001 at 09:46:46PM +0100,
Bernd Walter said words to the effect of;
> On Wed, Dec 19, 2001 at 08:06:20PM +0100, Maxime Henrion wrote:
> > Bernd Walter wrote:
> > > How can I add initalisation code to a library without needing to
> > > call a function in the usi
On Wed, Dec 19, 2001 at 08:06:20PM +0100, Maxime Henrion wrote:
> Bernd Walter wrote:
> > How can I add initalisation code to a library without needing to
> > call a function in the using application?
> > What I saw is that libc does something like this but havn't found
> > the starting point of t
Bernd Walter wrote:
> How can I add initalisation code to a library without needing to
> call a function in the using application?
> What I saw is that libc does something like this but havn't found
> the starting point of this.
There are two special functions for that : _init() which will be cal
[EMAIL PROTECTED] wrote:
>
> i need to TAILQ_INIT a queue at kernel startup .. how
> can i do it in my code?
> reg
Grep for "SYSINIT" in the kernel sources.
Do your initialization as late as possible, but before the
queue is used.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
>But, unfortunately, putting the console on a serial port creates
>vulnerabilities when DDB is enabled. You are, essentially, creating
>an unintentional backdoor into the system. Hence the problem.
ports/*/conserver is your friend!
--
Poul-Henning Kamp FreeBSD coreteam
: >generated, DDB is the only way to figure out what is going on.
: >securelevel is a mechanism which attempts to guarentee data security,
: >at least to a degree. These two items do not clash.
: >
:
:Anyway, as soon as you can physically access the PC, youD loose anyway,
:independe
>But, unfortunately, putting the console on a serial port creates
>vulnerabilities when DDB is enabled. You are, essentially, creating
>an unintentional backdoor into the system. Hence the problem.
ports/*/conserver is your friend!
--
Poul-Henning Kamp FreeBSD coreteam
: >generated, DDB is the only way to figure out what is going on.
: >securelevel is a mechanism which attempts to guarentee data security,
: >at least to a degree. These two items do not clash.
: >
:
:Anyway, as soon as you can physically access the PC, youD loose anyway,
:independ
Dag-Erling Smorgrav wrote:
> That's an excellent idea - it shouldn't be too hard to add a kernel
> option (say, DDB_RESTRICTED) and #ifndef the "dangerous" commands.
To achieve both higher security and kenel hackers convenience, I'd
submit following idea:
- If securelevel > 1, DDB is in restr
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> That's an excellent idea - it shouldn't be too hard to add a kernel
> option (say, DDB_RESTRICTED) and #ifndef the "dangerous" commands.
To achieve both higher security and kenel hackers convenience, I'd
submit following idea:
- If securelevel
Matthew Dillon writes:
> So making DDB 'secure-level friendly' would be a useful thing
> tgo do, I think. The idea is not to disable DDB, but to simply
> limit the actions that can be performed within it if the securelevel
> has been raised. The sysadmin would only be allowed to
Matthew Dillon <[EMAIL PROTECTED]> writes:
> So making DDB 'secure-level friendly' would be a useful thing
> tgo do, I think. The idea is not to disable DDB, but to simply
> limit the actions that can be performed within it if the securelevel
> has been raised. The sysadmin woul
On Tue, 7 Sep 1999, Nick Hibma wrote:
> Anyway, as soon as you can physically access the PC, youD loose anyway,
> independent of whether you can go into DDB to do things. You can reboot,
> boot a floppy. Yes you can do something about those things, but only to
> a limited extent.
Not without some
>I disagree quite strongly. DDB provides a mechanism to allow a
>sysadmin to obtain a greater amount of information from a panic
>situation then he could get otherwise. Being able to obtain this
>information does not run counter to running with a raised securelevel.
>
>
On Tue, 7 Sep 1999, KATO Takenori wrote:
> DDB does not provide enough security. Though securelevel cannot be
> changed,
>
> (1) Turn off power.
> (2) Boot as single-user mode.
Setting the console as insecure should protect against this.
> or
>
> (1) Turn off power.
>
On Tue, 7 Sep 1999, Nick Hibma wrote:
> Anyway, as soon as you can physically access the PC, youD loose anyway,
> independent of whether you can go into DDB to do things. You can reboot,
> boot a floppy. Yes you can do something about those things, but only to
> a limited extent.
Not without som
>I disagree quite strongly. DDB provides a mechanism to allow a
>sysadmin to obtain a greater amount of information from a panic
>situation then he could get otherwise. Being able to obtain this
>information does not run counter to running with a raised securelevel.
>
>
Matthew Dillon wrote:
> If the system winds up in a state where a kernel core cannot be
> generated, DDB is the only way to figure out what is going on.
> securelevel is a mechanism which attempts to guarentee data security,
> at least to a degree.
The problem is that DDB currently allo
Matthew Dillon wrote:
>I disagree quite strongly. DDB provides a mechanism to allow a
>sysadmin to obtain a greater amount of information from a panic
>situation then he could get otherwise. Being able to obtain this
>information does not run counter to running with a raised sec
On Tue, 7 Sep 1999, KATO Takenori wrote:
> DDB does not provide enough security. Though securelevel cannot be
> changed,
>
> (1) Turn off power.
> (2) Boot as single-user mode.
Setting the console as insecure should protect against this.
> or
>
> (1) Turn off power.
>
:> Though, as a side note, it should be noted that if you have DDB
:> enabled then lowering the secure level is pretty easy to do. If you
:> have access to the console, of course.
:
:It should also be noted that it makes no sense to enable DDB on
:systems that need to use elevated sec
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> If the system winds up in a state where a kernel core cannot be
> generated, DDB is the only way to figure out what is going on.
> securelevel is a mechanism which attempts to guarentee data security,
> at least to a degree.
The problem is tha
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>I disagree quite strongly. DDB provides a mechanism to allow a
>sysadmin to obtain a greater amount of information from a panic
>situation then he could get otherwise. Being able to obtain this
>information does not run counter to runni
:> Though, as a side note, it should be noted that if you have DDB
:> enabled then lowering the secure level is pretty easy to do. If you
:> have access to the console, of course.
:
:It should also be noted that it makes no sense to enable DDB on
:systems that need to use elevated se
Matthew Dillon wrote:
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course. We used this trick at BEST
> a couple of times. Still, I think this might quali
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course. We used this trick at BEST
> a couple of times. Still, I th
Matthew Dillon writes:
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course.
It should also be noted that it makes no sense to enable DDB on
systems that need to
:On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me
:that Matthew Dillon remarked
:>
:> Though, as a side note, it should be noted that if you have DDB
:> enabled then lowering the secure level is pretty easy to do. If you
:> have access to the console, of course. We u
:On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me
:that Matthew Dillon remarked
:>
:> Though, as a side note, it should be noted that if you have DDB
:> enabled then lowering the secure level is pretty easy to do. If you
:> have access to the console, of course. We
Matthew Dillon writes:
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course.
It should also be noted that it makes no sense to enable DDB on
systems that need t
On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me
that Matthew Dillon remarked
>
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course. We used th
On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me
that Matthew Dillon remarked
>
> Though, as a side note, it should be noted that if you have DDB
> enabled then lowering the secure level is pretty easy to do. If you
> have access to the console, of course. We used t
:
:KATO Takenori writes:
:> The kernel runs with four different levels of security.
:> ! Any super-user process can raise the security level, but no process
:> can lower it.
:
:How about "The security level can only be raised by the super-user,
:and cannot be lowered by anyone." instead?
:
:DE
:
:KATO Takenori <[EMAIL PROTECTED]> writes:
:> The kernel runs with four different levels of security.
:> ! Any super-user process can raise the security level, but no process
:> can lower it.
:
:How about "The security level can only be raised by the super-user,
:and cannot be lowered by any
KATO Takenori writes:
> The kernel runs with four different levels of security.
> ! Any super-user process can raise the security level, but no process
> can lower it.
How about "The security level can only be raised by the super-user,
and cannot be lowered by anyone." instead?
DES
--
Dag-E
KATO Takenori <[EMAIL PROTECTED]> writes:
> The kernel runs with four different levels of security.
> ! Any super-user process can raise the security level, but no process
> can lower it.
How about "The security level can only be raised by the super-user,
and cannot be lowered by anyone." ins
Bruce Evans <[EMAIL PROTECTED]> wrote:
> There used to be security holes that allowed root to lower `securelevel'
> using init. Rev.1.9 defends against any undiscovered holes.
How about following change?
--
*** init.8.ORIG Mon Sep 6 14:20:46 1999
--- init.8 Mon Sep 6 14:23:01 19
>Once securelevel has been increased, no process can decrease it because
>kernel always refuse decreasing it. This is inconsistent with the
>manual page of init:
>
> The kernel runs with four different levels of security. Any super-user
> process can raise the security level, but only in
>> There used to be security holes that allowed root to lower `securelevel'
>> using init. Rev.1.9 defends against any undiscovered holes.
>
>How about following change?
OK.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>> There used to be security holes that allowed root to lower `securelevel'
>> using init. Rev.1.9 defends against any undiscovered holes.
>
>How about following change?
OK.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Bruce Evans wrote:
> There used to be security holes that allowed root to lower `securelevel'
> using init. Rev.1.9 defends against any undiscovered holes.
How about following change?
--
*** init.8.ORIG Mon Sep 6 14:20:46 1999
--- init.8 Mon Sep 6 14:23:01 1999
***
*
>Once securelevel has been increased, no process can decrease it because
>kernel always refuse decreasing it. This is inconsistent with the
>manual page of init:
>
> The kernel runs with four different levels of security. Any super-user
> process can raise the security level, but only ini
~
~ >if anyone ever played with shells, maybe you'd like to have a look on
~ >restricted shell, I did for a couple of hours. the only thing I haven't
~ So break out via 'exec bash' ;-)
eh?;-) sh on OpenBSD (at least) has quite nice feature to disable exec'ing
any stuff which has path specified if
~
~ >if anyone ever played with shells, maybe you'd like to have a look on
~ >restricted shell, I did for a couple of hours. the only thing I haven't
~ So break out via 'exec bash' ;-)
eh?;-) sh on OpenBSD (at least) has quite nice feature to disable exec'ing
any stuff which has path specified i
45 matches
Mail list logo
