Date: Mon, 4 Jan 1999 13:33:38 +0900 (JST) From: kuma@jp.freebsd.org To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: horikawa@jp.freebsd.org Subject: docs/9305: add 'some '.Pa' macros in security.7 Message-ID: <199901040649.PAA18690@mail.nk.rim.or.jp>
next in thread | raw e-mail | index | archive | help
>Number: 9305 >Category: docs >Synopsis: To use some '.Pa' macros be better in security.7 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 3 22:50:01 PST 1999 >Closed-Date: >Last-Modified: >Originator: Norihiro Kumagai >Release: 3.0-19981225-SNAP >Organization: Japanese FreeBSD manual pages translation project >Environment: 3.0-19981225-SNAP (not 19981226) plus my modification reported in 'docs/9238' >Description: There are several path strings which I think should be applied to '.Pa' macros in the security.7 manpage. >How-To-Repeat: (nope) >Fix: Please consider the following patch. --- security.7-docs9238 Wed Dec 30 11:22:55 1998 +++ security.7 Mon Jan 4 13:14:31 1999 @@ -141,7 +141,7 @@ all other servers that handle login operations to refuse root logins, period, whether the right password is given or not. Allow direct root logins only via the system console. The -.Sq /etc/ttys +.Sq Pa /etc/ttys file comes in handy here and is secure by default on most systems, but a good sysadmin always checks to make sure. @@ -150,7 +150,7 @@ a few holes. But we make sure these holes require additional password verification to operate. One way to make root accessible is to add appropriate staff accounts to the wheel group -.Pq in /etc/group . +.Pq in Pa /etc/group . The staff members placed in the wheel group are allowed to .Sq su @@ -260,7 +260,13 @@ .Pp The other big potential root hole in a system are the suid-root and sgid binaries installed on the system. Most of these binaries, such as rlogin, -reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe, +reside in +.Pa /bin , +.Pa /sbin , +.Pa /usr/bin , +or +.Pa /usr/sbin . +While nothing is 100% safe, the system-default suid and sgid binaries can be considered reasonably safe. Still, root holes are occassionaly found in these binaries. A root hole was found in Xlib in 1998 that made xterm @@ -273,7 +279,9 @@ any suid binaries that nobody uses. A server with no display generally does not need an xterm binary. Sgid binaries can be almost as dangerous. If a hacker can break an sgid-kmem binary the -hacker might be able to read /dev/kmem and thus read the crypted password +hacker might be able to read +.Pa /dev/kmem +and thus read the crypted password file, potentially compromising any passworded account. A hacker that breaks the tty group can write to almost user's tty. If a user is running a terminal program or emulator with a talk-back feature, the hacker can potentially @@ -294,7 +302,7 @@ The only sure fire way is to *-out as many passwords as you can and use ssh or kerberos for access to those accounts. Even though the crypted password file -.Pq /etc/spwd.db +.Pq Pa /etc/spwd.db can only be read by root, it may be possible for a hacker to obtain read access to that file even if the attacker cannot obtain root-write access. @@ -325,7 +333,11 @@ with the NO_LKM option. .Pp But even if you turn off the bpf device, and turn off the module loader, -you still have /dev/mem and /dev/kmem to worry about. For that matter, +you still have +.Pa /dev/mem +and +.Pa /dev/kmem +to worry about. For that matter, the hacker can still write raw devices. To avoid this you have to run the kernel at a higher secure level... at least securelevel 1. The securelevel can be set with a sysctl on the kern.securelevel variable. Once you have @@ -368,7 +380,12 @@ and md5 binary and then ssh a shell command to the remote machine to md5 all the files in the system .Po -or, at least, the /, /var, and /usr partitions! +or, at least, the +.Pa / , +.Pa /var , +and +.Pa /usr +partitions! .Pc . The security machine copies the results to a file and diff's them against results from a previous run (or compares the results against its own >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901040649.PAA18690>