>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
38 matches
Mail list logo
