Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Oct 2012 14:15:48 +0400
From:      Peter Vereshagin <>
Subject:   Re: Sysctls and privacy
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

it's a -questions@ here, right? (=

2012/10/12 09:59:15 -0300 => To :
> In my system I use separate user accounts for running untrusted
> programs at the moment. While many will probably argue that jails
> are a superior solution, in my specific case its the inverse.

What's a specific of the case?

> I know FreeBSD is not ready by default to have multiple untrusted
> users in the system, at least from a security viewpoint. I have
> done quite a bit of changes to make the situation better.

What changes?

> However, there is something bugging me. Some sysctls apparently
> expose too much information about the system. Some examples: the
> number of context switches, the number of forks, the total used
> memory (at the byte level), the total used space for each file
> system (at the byte level) and even a graph of how my GEOM devices
> are organized!

What kind of danger is this? This system info expose seems nothing to do with
making the system work unexpectedly.

> I know some programs like gkrellm need this information to function,
> but on the other hand, I feel pretty uncomfortable with the
> information presented by gkrellm being logged. It's at the very least
> a loss of privacy.

You didn't mention you must have an outside network connection. Should your
untrusted software have it? Just unplug it otherwise.

> So, I would like to ask for a way to disable user access to all
> sysctls that are not needed by basic user programs (shell, terminal, etc).

You can make the special chroot/jail environment for the users keeping them
away from the access to the binaries exposing sysctls. And permit them the
write access only to the volumes mounted as '-o noexec'.

There should be the way(s) to bypass this, at the least one of the DSLs  e. g.
ruby, python, perl, php used in that environment may provide API for sysctls
or the modules can be built to use sysctl api from C. Thus you should keep
your C compiler and any of the soucres e. g. /usr/src to present on that

Even with that who knows if your software doesn't use sysctl(3) functions. But
the 'basic user programs' shouldn't.

> Also, if possible, I would like to have a group of users to whom
> these sysctls are accessible as an exception (to run gkrellm).

I don't think it's possible at the moment. Do you think this can be
implemented without performance loss? Sysctl is a kind of the kernel stuff...

How about emaulators/qemu, virtualbox, etc?

> Thanks for your time.

Peter Vereshagin <> ( pgp: A0E26627 

Want to link to this message? Use this URL: <>