A few thoughts..

[H. S.]

> On Tue, 29 Mar 2005 13:19:06 -0600 (CST)
> "H. S." <security at revolutionsp.com> wrote:
>
>
>> [USERNAME at SERVER:/home/USERNAME]$ ./dmesg
>> Copyright (c) 1992-2004 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> [...]
>> real memory  = 83886080 (80 MB)
>> avail memory = 72318976 (68 MB)
>
>> 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.
>
> If you don't want users to run random binaries put /home and /tmp on
> their own partitions and mount them noexec. Also note that users can
> still read that info by accessing /var/log/messages and /var/run/
> dmesg.boot
>

I do want them to run random binaries, such as psybncs, eggdrops,
shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is
noexec tho.

>> 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.
>
> Sounds like security through obscurity to me. If you don't trust your
> shell users put them in a jail, where any bad behaviour can be
> contained.
>

They need multiple IPs, and there are lots of users. Creating a jail for
each user is not pratical in any mean (firewall rules, number of jails,
disk space, to name a few). The ideal would be only root accessing this
information, so users would need a setuid binary in order to be able to
see such stuff. And since only the administrator could set the setuid
bit..

This could be compared to what was done in FreeBSD lately, I remember in
4.7 (and probably later, up to 4.10 I think) a user could see the full
connection lists (even connections from other users), only later the
kern.ps_showallprocs/security.bsd.see_other_uids took effect for these
matters too.

I don't know how hard would it be to implement this kind of information
containment in the heart of the system, and it surely could lead to many
discussing about what should be hidden from users and what shouldnt.
Personally, I don't like the hability of having users checking the kernel
message buffer, or seeing the vmstat / tcp statistics etc.

>> If you can't trust your logs.. This also poses another problem, with a
>> little patience, one can fill up /var.
>
>> Lastly, anyone knows if FreeBSD is getting systrace support ? I think of
>> it as a major drawback in the security field, one can do very
>> interesting
>> things with systrace. Added with other freebsd features (jails, etc), it
>> makes a very good security tool.
>
> Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you
> can achieve
> similar results.

Systrace is much more complex than mac.

>
> Cheers,
> --
> Miguel Mendez <flynn at energyhq.es.eu.org>
> http://www.energyhq.es.eu.org
> PGP Key: 0xDC8514F1
>
>