Re: Sysctls and privacy
Hello. 2012/10/13 12:09:39 -0300 schu...@ime.usp.br = To Peter Vereshagin : y Hello. it's a -questions@ here, right? (= Indeed. :-) Ouch! it's already not... But I Cc: there. Oops? What's a specific of the case? I need quite a lot of such jails, with some being able to see others, including the case where one jail may be visible to many. However, a jail being visible does not mean it can be modified by the observing jail. 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 The first implementation I thought of was using users and groups. I imagine I can do this with jails and read-only mounts, but I would like to avoid making a clean system per jail since disk space would not be enough. 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. (= Also, the configuration of such environment is much, much simpler than a jails version. 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. To be sincere, I have not discarded the possibility of a jails solution with clever mounts to preserve space, but it did not occur to me yet. What changes? Changing the default permissions on devices (e.g sound), jail goes beyond with its jail_devfs_rules not allowing any file to be setuid and be visible to ordinary users, 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... patching some ports to avoid attacks on /tmp (X server), Sounds interesting but doesn't seem googleable to me. Any URLs for xorg patches and/or for the list of such a ports please? exercising memory and process limits via rctl, Ouch! a RELENG_9 feature... changing some system configurations (see_other_uids, etc), disabling access to the system log, stopping useless (to me) daemons, setting per user ZFS quotas and probably a few more I can't remember at the moment. What kind of danger is this? This system info expose seems nothing to do with making the system work unexpectedly. Indeed, but then all users might infer which programs are running and when. How could the one know out that from overall system statistics only? It's not about consistency loss, it's about privacy loss. ok but that can be the loss of a privacy of some other user? You didn't mention you must have an outside network connection. Should your untrusted software have it? Just unplug it otherwise. The untrusted software runs for a reason, and that is I need its output. Some outputs are not that amenable to verification (pdf files for instance), and I can not exclude the possibility I myself might post some of these outputs online, for instance. They may however, contain the logs. Sure. You can convert PDFs to the set of images, reassemble them into your own PDFs without the logs and post then. So without the need for the outside network connectivity there shouldn't be much care. (= 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 environment. Even with that who knows if your software doesn't use sysctl(3) functions. But the 'basic user programs' shouldn't. That is a real solution for the problem I have asked. However, for my use cases not being able to produce executables is too restrictive. 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... Assuming you did implement the user blocking code for the sysctls, I Can't remind that. (= couldn't help but imagine the group one would be one added if that checks membership of an UID to a group. Err... what? How about emaulators/qemu, virtualbox, etc? They are not security tools. 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'
Re: Sysctls and privacy
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
Re: Sysctls and privacy
On Sun, Oct 14, 2012 at 8:33 PM, schu...@ime.usp.br wrote: 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. Says who? Is this your requirement? Why? 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. If this is really a serious concern of yours, you have much bigger fish to fry than sysctl(8). -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sysctls and privacy
Says who? Is this your requirement? Why? I meant I don't see how it can be done differently. If this is really a serious concern of yours, you have much bigger fish to fry than sysctl(8). Can you elaborate a bit more on this please? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Sysctls and privacy
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. 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. 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! 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. 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). Also, if possible, I would like to have a group of users to whom these sysctls are accessible as an exception (to run gkrellm). Thanks for your time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
