kern/161350: securelevel 3 can be lowered thru ddb
>Number: 161350 >Category: kern >Synopsis: securelevel 3 can be lowered thru ddb >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 07 05:40:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: David O'Brien >Release:FreeBSD 9.0-CURRENT i386 >Organization: The FreeBSD Project >Environment: System: FreeBSD dragon.NUXI.org 9.0-CURRENT FreeBSD 9.0-CURRENT #669 r223636M: Wed Jun 29 17:54:57 PDT 2011 ro...@dragon.nuxi.org:/sys/i386/compile/DRAGON i386 >Description: 'securelevel' is intended to disallow attempts to lower its value (when set to 1 or larger). However, one may trivially enter ddb and lower the value. Given the behavior changes documented in security(7), I believe this to be against the spirit of 'securelevel' and against the desire of users of securelevel at 1+. >How-To-Repeat: # sysctl kern.securelevel=3 kern.securelevel: 0 -> 3 # sysctl kern.securelevel=0 kern.securelevel: 3 sysctl: kern.securelevel: Operation not permitted # sysctl debug.kdb.enter=1 KDB: enter: sysctl debug.kdb.enter [ thread pid 33529 tid 100134 ] Stopped at 0x808229ab = kdb_enter+0x3b: movq $0,0x92d732(%rip) db> print *(prison0 + 0xfc) 3 db> write (prison0 + 0xfc) 0 0x8103f85c = prison0+0xfc 0x3 = 0 db> print *(prison0 + 0xfc) 0 db> c debug.kdb.enter: 0 -> 0 # sysctl kern.securelevel=0 kern.securelevel: 0 -> 0 >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/156817: WITHOUT_CDDL and NO_CTF ignored if WITH_CTF defined
>Number: 156817 >Category: bin >Synopsis: WITHOUT_CDDL and NO_CTF ignored if WITH_CTF defined >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 04 15:30:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: David O'Brien >Release:FreeBSD 9.0-CURRENT i386 >Organization: The FreeBSD Project >Environment: System: FreeBSD dragon.NUXI.org 9.0-CURRENT FreeBSD 9.0-CURRENT #664 r221012M: Mon Apr 25 08:32:28 PDT 2011 r...@dragon.nuxi.org:/sys/i386/compile/DRAGON i386 >Description: Starting with r206082 (I believe), the "-DNO_CTF" became ignored in the "stage 1.1: legacy release compatibility shims", "stage 1.2: bootstrap tools", "stage 2.3: build tools", and "stage 3: cross tools" parts of the build if WITH_CTF=yes is in '/etc/src.conf'. John Birrell's claim in r179233 is that these stages of the build do not require CTF conversion. Additionally, it appears that WITH_CTF now has higher precidence than WITHOUT_CDDL. [WITH_CTF=yes in /etc/src.conf combined with 'make -DWITHOUT_CDDL buildworld' or WITHOUT_CDDL=yes in /etc/make.conf] If so, I feel this is wrong as if someone has set WITHOUT_CDDL they have strong licensing needs (restrictions). And so not running the CTF tools is of lesser importance than accidently falling into a legal problem. >How-To-Repeat: Perform builds with the above settings and look at the output >Fix: revisit r206082. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/156579: Tweak to Makefile.in to document which kernel is installed
On Wed, May 04, 2011 at 04:34:10AM -0700, David Wolfskill wrote: > Color me foolish. [..] > >>> Installing kernel GENERIC ALBERT JANUS > which is ... well, neither useful nor the intent. > > I'll see if I can figure out a clean way to acheive the intent. Please let me know if you have an update. -- -- David (obr...@freebsd.org) ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
