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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121014223328.16140uoyo4x5dii0>