Re: Init(8) cannot decrease securelevel
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 only be allowed to issue passive commands, cont, and 'panic'. The sysadmin would not be allowed to modify the running system. That's an excellent idea - it shouldn't be too hard to add a kernel option (say, DDB_RESTRICTED) and #ifndef the "dangerous" commands. DES (must... write... patches...) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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, DDB is in restricted mode. - If securelevel 1 and an option is defined, DDB is in powerful mode. - If securelvel 1, DDB is in powerful mode. ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease 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 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. : :Nick I wasn't really thinking of the console-on-vty case. I was thinking of the console-on-serial-port case. When you have a rack of PC's you usually hang the console off a serial port and throw it into a portmaster or another machine w/ a multi-port card in it. There are two reasons for doing this. First in order to be able to log all messages sent to the console on a separate box, and second to be able to perform maintenance on the machines deal with panics, lockups, and other situations for which DDB might be useful without having to haul the card with the video monitor and keyboard physically over to the machine. This also comes in useful when dealing with network attacks that make it impossible to log into a machine the normal way. 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. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 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. These two items do not clash. 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. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 noticing in a big way. DDB is a silent attack. -- - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 would only be allowed to issue passive commands, cont, and 'panic'. The sysadmin would not be allowed to modify the running system. That's an excellent idea - it shouldn't be too hard to add a kernel option (say, DDB_RESTRICTED) and #ifndef the dangerous commands. DES (must... write... patches...) -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 1, DDB is in restricted mode. - If securelevel 1 and an option is defined, DDB is in powerful mode. - If securelvel 1, DDB is in powerful mode. ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease 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 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. : :Nick I wasn't really thinking of the console-on-vty case. I was thinking of the console-on-serial-port case. When you have a rack of PC's you usually hang the console off a serial port and throw it into a portmaster or another machine w/ a multi-port card in it. There are two reasons for doing this. First in order to be able to log all messages sent to the console on a separate box, and second to be able to perform maintenance on the machines deal with panics, lockups, and other situations for which DDB might be useful without having to haul the card with the video monitor and keyboard physically over to the machine. This also comes in useful when dealing with network attacks that make it impossible to log into a machine the normal way. 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. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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
Re: Init(8) cannot decrease securelevel
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 lower it. Is there any security problem to implement this? If no, could someone review following patch? The patch just backs out rev.1.9: RCS file: /home/ncvs/src/sys/kern/kern_mib.c,v Working file: kern_mib.c head: 1.25 ... revision 1.9 date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 Don't ever allow lowering the securelevel at all. Allowing it does nothing good except of opening a can of (potential or real) security holes. People maintaining a machine with higher security requirements need to be on the console anyway, so there's no point in not forcing them to reboot before starting maintenance. Agreed by: hackers, guido There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 *** *** 92,99 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but only ! .Nm can lower it. The security levels are: .Bl -tag -width flag --- 92,98 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but no process can lower it. The security levels are: .Bl -tag -width flag -- ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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." instead? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
: :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." instead? : :DES :-- :Dag-Erling Smorgrav - [EMAIL PROTECTED] 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 qualify as a bug in the securelevel implementation. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 use elevated securelevels. -- Greg Black -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
: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 trick at BEST : a couple of times. Still, I think this might qualify as a bug in : the securelevel implementation. : :I don't know about 'bug in securelevel implementation'... :For DDB to be DDB, you have to be able to tweak the running kernel any :which way outside of its control. For securelevel to be securelevel, you :have to prevent changes to X, Y, and Z, no matter how they're changed. : :I think it's more of a 'DDB is antithecal to securelevel'. Calling it a :bug in securelevel is like calling lack of cargo space a bug in a Geo :Metro. : :Matthew Fuller (MF4839) |[EMAIL PROTECTED] Well, if you are using DDB for kernel debugging via remote gdb, that is so. In the production installation at BEST we leave DDB turned on in order to be able to track panics and control dumps. We do not use it for remote gdb debugging. I think the vast majority of production installations which use DDB only need the trace, show, and panic capability. They probably do not need to issue writes into kernel memory. In these installations DDB is necessary to deal with system panics, so turning it off is not really an option. 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 issue passive commands, cont, and 'panic'. The sysadmin would not be allowed to modify the running system. A hacker in a similar situation would not be able to do anything beyond crash the machine. I would rather a machine crash then give a hacker the ability to defeat the security mechanism in order to gain access to the system and modify data. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
: 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 securelevels. : :-- :Greg Black -- [EMAIL PROTECTED] 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 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. These two items do not clash. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 with a raised securelevel. 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. These two items do not clash. If console works and crackers can use it, protecting securelevel from DDB does not provide enough security. Though securelevel cannot be changed, (1) Turn off power. (2) Boot as single-user mode. (3) Do what crackers want. or (1) Turn off power. (2) Remove HDD. (3) Mount on another FreeBSD box. (4) Edit a file in the HDD. (5) Return HDD. (6) Reboot. is available. ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 currently allows too much freedom. It needs to disable various commands as the securelevel is raised. Working out which commands is the non-trivial exercise - especially since you can add new ones with DB_COMMAND(). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 noticing in a big way. DDB is a silent attack. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
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 anyone. instead? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
: :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 anyone. instead? : :DES :-- :Dag-Erling Smorgrav - d...@flood.ping.uio.no 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 qualify as a bug in the securelevel implementation. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 trick at BEST a couple of times. Still, I think this might qualify as a bug in the securelevel implementation. I don't know about 'bug in securelevel implementation'... For DDB to be DDB, you have to be able to tweak the running kernel any which way outside of its control. For securelevel to be securelevel, you have to prevent changes to X, Y, and Z, no matter how they're changed. I think it's more of a 'DDB is antithecal to securelevel'. Calling it a bug in securelevel is like calling lack of cargo space a bug in a Geo Metro. -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
: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 trick at BEST : a couple of times. Still, I think this might qualify as a bug in : the securelevel implementation. : :I don't know about 'bug in securelevel implementation'... :For DDB to be DDB, you have to be able to tweak the running kernel any :which way outside of its control. For securelevel to be securelevel, you :have to prevent changes to X, Y, and Z, no matter how they're changed. : :I think it's more of a 'DDB is antithecal to securelevel'. Calling it a :bug in securelevel is like calling lack of cargo space a bug in a Geo :Metro. : :Matthew Fuller (MF4839) |fulle...@over-yonder.net Well, if you are using DDB for kernel debugging via remote gdb, that is so. In the production installation at BEST we leave DDB turned on in order to be able to track panics and control dumps. We do not use it for remote gdb debugging. I think the vast majority of production installations which use DDB only need the trace, show, and panic capability. They probably do not need to issue writes into kernel memory. In these installations DDB is necessary to deal with system panics, so turning it off is not really an option. 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 issue passive commands, cont, and 'panic'. The sysadmin would not be allowed to modify the running system. A hacker in a similar situation would not be able to do anything beyond crash the machine. I would rather a machine crash then give a hacker the ability to defeat the security mechanism in order to gain access to the system and modify data. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 use elevated securelevels. -- Greg Black -- g...@acm.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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, I think this might qualify as a bug in the securelevel implementation. I also think it should be in manual page. But, I don't think it should be called `bug.' When an administrator maintains a machine with higher security, he/she must be careful with not only the securelevel also many other points, and may remove options for kernel hackers. ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
: 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 securelevels. : :-- :Greg Black -- g...@acm.org 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 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. These two items do not clash. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 running with a raised securelevel. 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. These two items do not clash. If console works and crackers can use it, protecting securelevel from DDB does not provide enough security. Though securelevel cannot be changed, (1) Turn off power. (2) Boot as single-user mode. (3) Do what crackers want. or (1) Turn off power. (2) Remove HDD. (3) Mount on another FreeBSD box. (4) Edit a file in the HDD. (5) Return HDD. (6) Reboot. is available. ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 that DDB currently allows too much freedom. It needs to disable various commands as the securelevel is raised. Working out which commands is the non-trivial exercise - especially since you can add new ones with DB_COMMAND(). Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease 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. (2) Remove HDD. (3) Mount on another FreeBSD box. (4) Edit a file in the HDD. (5) Return HDD. (6) Reboot. is available. There isn't a whole lot you can do to protect a system against crackers who have physical access to the system. Heavily armed guards would help, but I don't expect to see them as part of the base distribution anytime soon. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 lower it. Is there any security problem to implement this? If no, could someone review following patch? The patch just backs out rev.1.9: RCS file: /home/ncvs/src/sys/kern/kern_mib.c,v Working file: kern_mib.c head: 1.25 ... revision 1.9 date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 Don't ever allow lowering the securelevel at all. Allowing it does nothing good except of opening a can of (potential or real) security holes. People maintaining a machine with higher security requirements need to be on the console anyway, so there's no point in not forcing them to reboot before starting maintenance. Agreed by: hackers, guido There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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 *** *** 92,99 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but only ! .Nm can lower it. The security levels are: .Bl -tag -width flag --- 92,98 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but no process can lower it. The security levels are: .Bl -tag -width flag -- ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
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
