Re: A few thoughts..

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 03/31/05

  • Next message: David Leimbach: "Re: organization" 
    Date: Thu, 31 Mar 2005 02:41:25 +0000 (GMT)
To: "H. S." <security@revolutionsp.com>

    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

    _______________________________________________
    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"

  • Next message: David Leimbach: "Re: organization"

    Relevant Pages

    • Re: A few thoughts..
      ... I didn't know this MIB! ... system information was retrieved by ... > using the sysctl MIB, ... I've just begun trying to understand MAC. ...
      (freebsd-hackers)
    • Re: Problems with WMI
      ... In order to retrieve several system information. ... Maybe I did not communicate clear enough that everythings works fine on ...
      (microsoft.public.vb.general.discussion)
    • Re: Problems with WMI
      ... In order to retrieve several system information. ... Maybe I did not communicate clear enough that everythings works fine on many ...
      (microsoft.public.vb.general.discussion)
    • Access Denied !!!!! Why?
      ... I have this problem with my system information tool.For a ... server on this computer.Have an administrator change your ... retrieve my Network Diagnostics using Help and Support ...
      (microsoft.public.windowsxp.security_admin)