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 would
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 1,
: 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,
:independent
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.
If
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 someone
Matthew Dillon dil...@apollo.backplane.com 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
Dag-Erling Smorgrav d...@flood.ping.uio.no 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
: 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,
:independent
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
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
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 init
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 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 init
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."
:
: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
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
: 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
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 running
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 that DDB
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
KATO Takenori k...@ganko.eps.nagoya-u.ac.jp 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
:
:KATO Takenori k...@ganko.eps.nagoya-u.ac.jp 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
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 this
: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
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
Matthew Dillon dil...@apollo.backplane.com 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,
: 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
Matthew Dillon dil...@apollo.backplane.com 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
Matthew Dillon dil...@apollo.backplane.com 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
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.
(2)
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 init can
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 init can
Bruce Evans b...@zeta.org.au 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
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
35 matches
Mail list logo
