A few thoughts..

[H. S.]

> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>