Attachment 55811 Details for Bug 84266 – file.diff

[patch] file.diff

file.diff (text/plain), 3.25 KB, created by Gary W. Swearingen on 2005-07-29 04:50:20 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Gary W. Swearingen

Created: 2005-07-29 04:50:20 UTC

Size: 3.25 KB

patch

obsolete

>--- /pr/work/security..orig.7	Thu Jul 28 19:58:11 2005
>+++ /pr/work/security.7	Thu Jul 28 20:33:59 2005
>@@ -21,7 +21,7 @@
> .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> .\" SUCH DAMAGE.
> .\"
>-.\" $FreeBSD: src/share/man/man7/security.7,v 1.39 2004/08/07 04:40:20 imp Exp $
>+.\" $FreeBSD: Exp $
> .\"
> .Dd September 18, 1999
> .Dt SECURITY 7
>@@ -498,14 +498,14 @@
> .Xr bpf 4
> device or other sniffing device on a running kernel.
> To avoid these problems you have to run
>-the kernel at a higher secure level, at least securelevel 1.
>-The securelevel can be set with a
>+the kernel at a higher secure level, at least secure level 1.
>+The secure level can be set with a
> .Xr sysctl 8
> on the
> .Va kern.securelevel
> variable.
> Once you have
>-set the securelevel to 1, write access to raw devices will be denied and
>+set the secure level to 1, write access to raw devices will be denied and
> special
> .Xr chflags 1
> flags, such as
>@@ -515,7 +515,7 @@
> that the
> .Cm schg
> flag is set on critical startup binaries, directories, and
>-script files \(em everything that gets run up to the point where the securelevel
>+script files \(em everything that gets run up to the point where the secure level
> is set.
> This might be overdoing it, and upgrading the system is much more
> difficult when you operate at a higher secure level.
>@@ -533,6 +533,62 @@
> It should be noted that being too draconian in
> what you attempt to protect may prevent the all-important detection of an
> intrusion.
>+.Pp
>+The kernel runs with five 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
>+.It Ic -1
>+Permanently insecure mode \- always run the system in level 0 mode.
>+This is the default initial value.
>+.It Ic 0
>+Insecure mode \- immutable and append-only flags may be turned off.
>+All devices may be read or written subject to their permissions.
>+.It Ic 1
>+Secure mode \- the system immutable and system append-only flags may not
>+be turned off;
>+disks for mounted file systems,
>+.Pa /dev/mem ,
>+.Pa /dev/kmem
>+and
>+.Pa /dev/io
>+(if your platform has it) may not be opened for writing;
>+kernel modules (see
>+.Xr kld 4 )
>+may not be loaded or unloaded.
>+.It Ic 2
>+Highly secure mode \- same as secure mode, plus disks may not be
>+opened for writing (except by
>+.Xr mount 2 )
>+whether mounted or not.
>+This level precludes tampering with file systems by unmounting them,
>+but also inhibits running
>+.Xr newfs 8
>+while the system is multi-user.
>+.Pp
>+In addition, kernel time changes are restricted to less than or equal to one
>+second.
>+Attempts to change the time by more than this will log the message
>+.Dq Time adjustment clamped to +1 second .
>+.It Ic 3
>+Network secure mode \- same as highly secure mode, plus
>+IP packet filter rules (see
>+.Xr ipfw 8 ,
>+.Xr ipfirewall 4
>+and
>+.Xr pfctl 8 )
>+cannot be changed and
>+.Xr dummynet 4
>+or
>+.Xr pf 4
>+configuration cannot be adjusted.
>+.El
>+.Pp
>+The secure level is discussed further in
>+.Xr init 8
>+and can be configured with variables documented in
>+.Xr rc.conf 8 .
> .Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
> When it comes right down to it, you can only protect your core system
> configuration and control files so much before the convenience factor

Actions: View | Diff

Attachments on bug 84266: 55811 | 55812