Date: Thu, 31 Mar 2005 14:10:27 -0600 (CST) From: "H. S." <security@revolutionsp.com> To: freebsd-hackers@freebsd.org Subject: Re: A few thoughts.. Message-ID: <49328.81.84.174.37.1112299827.squirrel@mail.revolutionsp.com> In-Reply-To: <Pine.NEB.3.96L.1050331023426.31268B-100000@fledge.watson.org> References: <61910.81.84.174.37.1112123946.squirrel@mail.revolutionsp.com> <Pine.NEB.3.96L.1050331023426.31268B-100000@fledge.watson.org>
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.
>
Very nice, I didn't know this MIB!
Thanks for the tip :-)
>> 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.
>
I've just begun trying to understand MAC. Is it possible to block this or
that sysctl MIB to users using MAC? MAC is very complex, I had no idea.I
thought it was mostly about ACLs, but after a bit of reading, now I know I
was wrong.
> Robert N M Watson
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49328.81.84.174.37.1112299827.squirrel>