Date: Sun, 14 Oct 2012 18:01:48 +0400 From: Peter Vereshagin <peter@vereshagin.org> To: schultz@ime.usp.br Cc: freebsd-questions@freebsd.org Subject: Re: Sysctls and privacy Message-ID: <20121014140148.GA5344@external.screwed.box> In-Reply-To: <20121013120939.18067gfy2u4vdzjn@webmail.ime.usp.br> References: <20121012095915.470864k9735iy883@webmail.ime.usp.br> <20121013101545.GA21274@external.screwed.box> <20121013120939.18067gfy2u4vdzjn@webmail.ime.usp.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello.
2012/10/13 12:09:39 -0300 schultz@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' includes
'privacy', sorry.
> Both qemu and virtualbox don't guarantee
> the code isolated will not interfere with the host.
But it seems to. What if the code isolated doesn't interfere?
> Also, the memory
> usage patterns of these programs are not exactly efficient (in the
> case where the sum of all "jail" limits is large but actual usage is
> small).
Do you mean here the emulators never release memory allocated once? And why
jail limits matter after that? Clarify please.
> Thank you for the comprehensive answer.
Took some avdvice from 'Leadership Cookbook"s like 'Always thank a one only
for the something" ? (=
--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121014140148.GA5344>