Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Jun 2008 23:47:09 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Ivaylo Mateev <mateev@cns-consulting.org>
Cc:        hackers@freebsd.org
Subject:   Re: Securelevels
Message-ID:  <20080629044709.GA76555@dan.emsphone.com>
In-Reply-To: <200806290313.21720.mateev@cns-consulting.org>
References:  <200806290313.21720.mateev@cns-consulting.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jun 29), Ivaylo Mateev said:
> I think I found a bug.
> 
> [strato@darkstar /usr/home/strato]$ sudo sysctl kern.securelevel
> kern.securelevel: 2
> [strato@darkstar /usr/home/strato]$ kgdb
> kgdb: /dev/mem: Permission denied
> [strato@darkstar /usr/home/strato]$ sudo kgdb
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> 
> I am running in securelevel 2. That means nithing can have direct access 
> to /dev/mem, acording to man security:
> 
> 1 Secure mode - the system immutable and system append-only flags may
>   not be turned off; disks for mounted file systems, /dev/mem and
>   /dev/kmem may not be opened for writing; /dev/io (if your platform
>   has it) may not be opened at all; kernel modules (see kld(4)) may
>   not be loaded or unloaded.
> 
> 2 Highly secure mode - same as secure mode, plus disks may not be
>   opened for writing (except by mount(2)) whether mounted or not.
>   This level precludes tampering with file systems by unmounting
>   them, but also inhibits running newfs(8) while the system is multi-
>   user.

# truss kgdb < /dev/null |& grep /dev/mem
open("/dev/mem",O_RDONLY,00)                     = 4 (0x4)
#

Read-only opens of /dev/mem are allowed.  "kgdb -w" should fail,
however.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080629044709.GA76555>