Date: Thu, 31 Mar 2005 02:41:25 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: "H. S." <security@revolutionsp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. Message-ID: <Pine.NEB.3.96L.1050331023426.31268B-100000@fledge.watson.org> In-Reply-To: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Mar 2005, H. S. wrote: > My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded > a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could > have access to this system information. The same goes for systat , > vmstat, and all these commands that (most people think) shouldn't be > available for regular users. dmesg is implemented as an unprivileged program that uses an unprivileged sysctl to retrieve the message buffer, kern.msgbuf. You can set the sysctl security.bsd.unprivileged_read_msgbuf to 0 to block unprivileged reading of the buffer. > Shouldn't this information be protected at kernel level? Am I missing > something I can do about this ? Because this method works with > everything that ressembles permissions in order to hide system > information that can be obtained without root privileges. In essense, yes. Historically, system information was retrieved by programs using /dev/mem, which required privilege. In that scenario, deleting or removing set{ug}id from /sbin/dmesg (et al) removed the ability to retrieve the information for an unprivileged user. Changes were made to limit the use of privileged programs, which represent a substantially risky approach (privileged code rather than a controlled interface), FreeBSD has generally moved to exporting system information using the sysctl MIB, which generally doesn't require privilege. Some system export MIB entries make use of access control to limit the export of system information -- for example, we export process information for use by ps(1) using sysctl, but the sysctls in question will check whether the user has the right to retrieve information on specific processes (such as with jail, or security.bsd.see_other_uids=0). However, this approach has not been taken universally with sysctls, because it adds moderate complexity to the implementation, and adding restrictions to many of the MIB entries isn't useful in most environments. Using the MAC Framework, it's possibel to construct a module that would restrict access to a broad range of sysctls -- however, this also prevents calls like gethostname() from succeeding, so this approach also would have to be taken cautiously. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050331023426.31268B-100000>