Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Oct 2012 22:33:28 -0300
From:      schultz@ime.usp.br
To:        Peter Vereshagin <peter@vereshagin.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Sysctls and privacy
Message-ID:  <20121014223328.16140uoyo4x5dii0@webmail.ime.usp.br>
In-Reply-To: <20121014140148.GA5344@external.screwed.box>
References:  <20121012095915.470864k9735iy883@webmail.ime.usp.br> <20121013101545.GA21274@external.screwed.box> <20121013120939.18067gfy2u4vdzjn@webmail.ime.usp.br> <20121014140148.GA5344@external.screwed.box>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> Did you specify elsewhere what a 'visible' does mean to you?
>
>   - if this means network connectivity then you can put jails on the same
>     network, e. g. the same address on a lo(4) interface
>
>   - if this means a read-only access to the directory located outside of a
>     jail then her4e is the trick:
>
>       mount_nullfs -o ro /path/to/inject /your/jail/mount/detination

I did mean the second case. Your solution seems reasonable. Only
change I would do is check for symlinks in the path within the jail
roots to avoid symlink attacks.

> The same trick can be done for every directory the freebsd base system
> consists of. Excluding those different for each jail, e. g. /var,  
> /etc. Nullfs
> daesn't consume your disk space except for additional fstab lines, something
> about a dozen per jail. (=

Here is the catch. I know I can read-only mount most static filesystems
from a template. However, the mutable ones have to be copied. This means
installing ports forces me to copy /usr/local, which is around half a
gigabyte (I have some pre-installed ports).

I have been looking into unionfs to solve this, but the BUGS section in
the man page scared me a bit. :-)

> I don't think so. It's a task of the configuration of a second system without
> hardware initialization and so on, and then spreading your configs around
> other jails.

I mean configuring a user account is much simpler than configuring a jail.
Still this is not at all a good reason not to use jails. :-)

> jail goes beyond with its jail_devfs_rules

I mean these changes are necessary in a user-based protection model.

> What do you mean 'visible' here? Do you just chmod a-rwx on them? Say, to
> avoid listing the /usr/bin/su you should chmod a-rx /usr/bin which  
> is far from
> the best idea...

I either chmod ug-s or chmod o-rwx.

> Sounds interesting but doesn't seem googleable to me. Any URLs for xorg
> patches and/or for the list of such a ports please?

I didn't find any URL too. The fact is the x11-servers/xorg-server has
the path /tmp/.X[n]-lock for the lock file hardcoded. Since I ended up
using many small Xephyr instances to isolate GUI applications, someone
could use that file before to prevent my application from starting. So
I myself made the (very small) patch, and compiled the port manually.

> Ouch! a RELENG_9 feature...

If it does not go away in future versions I am happy with it.

> How could the one know out that from overall system statistics only?

Because someone might know the program memory, cpu or network usage patterns
and extrapolate from the data. Firefox is a good example because it
eats up huge amounts of RAM and garbage collects it quite fast. So when
that pattern shows up you know someone is probably using Firefox.
This, of course, also applies to other programs.

Also, if you do know someone is going to run a single program in the
machine, you might just have the memory footprint of that program by
subtraction, and that reveals quite a lot.

I do realize this has a great deal of paranoia, but it is an issue
nonetheless.

> ok but that can be the loss of a privacy of some other user?

Not if you have a single (human) user on the machine. Also, this
is quite informal reasoning.

> Sure. You can convert PDFs to the set of images, reassemble them  
> into your own
> PDFs without the logs and post then.

Not without loss of quality, indexing and compactness. Also, steganography
might be employed by the attacker.

> So without the need for the outside network connectivity there shouldn't be
> much  care. (=

This can be done, it just is not practical. Additionally, unfortunately
some untrusted users have to have internet connection. I know they can
gather important personal identifying information (/etc/passwd). In
this sense, I have another question: can a user of jails realize he or
she is not in a real FreeBSD system? If so, how much about the host
can he or she gather?

> Can't remind that. (=

I never said you did implement it. :-)

> Err... what?

Before serving a sysctl, the kernel could check if UID == 0 or
if UID is in the special GID.

> But they can hide the system statistics and improve the privacy, the what you
> need having the consistency already? I have no idea if 'security' includes
> 'privacy', sorry.

Using emulators/virtual machines improves the situation for sure, but yet
that is not a silver bullet in terms of security, since these tools are
designed to be compatibility tools, not security tools. Also, the added
overhead does not justify it.

> But it seems to. What if the code isolated doesn't interfere?

If it does not interfere then we have a proper (but slow) solution.

> Do you mean here the emulators never release memory allocated once? And why
> jail limits matter after that? Clarify please.

Yes, that is the point. There are situations in which the total memory
used by a program is very high and the maximum memory used at any time
is very low. The memory used by the emulator at any time is the total
memory due to its inability to free used memory and give it back to the
host OS. This can be very poor especially when it reaches swap in
comparison to an OS-based solution.

Say, I have an emulator whose memory limit is 64GB and I have only 4GB
physical RAM. The emulating program might use just 2GB memory at a time
but uses 256GB total. Then the emulator uses around 64GB generally and
that gets into my swap, while if the program ran natively that might
not happen.


All in all, I think you convinced me to give jails a try. :-)





Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20121014223328.16140uoyo4x5dii0>