Date: Tue, 24 Nov 2015 23:23:46 +0100 From: Mariusz Zaborski <oshogbo@FreeBSD.org> To: freebsd-arch@freebsd.org Cc: cl-capsicum-discuss@lists.cam.ac.uk Subject: Casper new architecture. Message-ID: <20151124222346.GA91383@jarvis.chello.pl>
next in thread | raw e-mail | index | archive | help
--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello,
I have finally a new version of Casper and I wanted to share with you. [1]
I would like to ask for code review and if possible for some people to
run tests on thier machines.
We decided to change a few things in the Casper architecture:
The first one is that Capser isn't a daemon any more.
Now, after calling the cap_init(3) function Casper will fork from
it's original process, using pdfork(2). Thanks to the changes in r286698
the pdforking will not have any affects to the original process.
Forking from a process has a lot of advantages:
1* We have the same cwd as the original process (so the programmer must be
aware that if he changed the original process working directory, Casper
directory will not be changed). But I feel that this is acceptable limitation.
2* The same uid, gid and groups.
3* The same MAC labels.
4* The same descriptor table. This is important for a filesystem service
because with the old Casper for example, process substitution was not
possible. When the filesystem service arrives, I want to add some special
flags that will tell zygote processes to not clear file descriptors. Right
know for the service, all fd are closed.
5* The same routing table. We can change routing table for process using
setfib(2).
6* The same umask.
7* The same cpuset(1).
And I probably missed some things on this list.
I decided to remove the libcapsicum library. In my opinion Capser is
connected with capsicum, but Casper can be used also with different sandbox
techniques. Now I would like to refer to it just as libcasper.
Second change is that Casper will not execute any binary files.
Now every services (cap_{dns,grp,etc.}) will be in form of shared library.
I don't see, right now, any advantages on keeping services as executable
binaries. It's a little bit problematic to manage services when we don't have a
global daemon. Services can be in different locations and hard coding one path
(like before /etc/casperd) didn't feel right. On the other hand, adding additional
arguments to cap_init() also don't convince me, because how can the programmer
guess where the administrator will put the Casper services. So in my opinion using
dynamic libraries right know is the best option. Programs need to know the replacement
API (for example cap_gethostbyname which replace gethostbyname) so it needs to
include some library (before just one global library, libcapsicum), so why not
store services inside that library? Thanks to that we also have an implementation of
service and replaced API in one place, so we don't need to jump between libexec
and lib directories.
I hope that you like new architecture of Casper.
Cheers,
Mariusz
[1] https://people.freebsd.org/~oshogbo/casper.patch
--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWVONjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0I3NjA5RUE2Q0JEMTM5QUE5NUU2Mjg1
NDFFNzc1RTk2N0Y4OUNGAAoJEFQed16Wf4nPR/IQALnV/fFTTZFOWQdIFj8MxeE7
9E8y0SwSAKyDi/3w+LaVmlfoxe1GlejoojzTpSGAMw5NKpzqzvDcYl8q5j/k/1nN
BHW4zLHqNXRgNvjnC/EZGApGpfqJC+ZDQacOIEI7YAqEmbRi00fl4mRcEpr4kmf4
gNjuZBAHGVYIZ3BlwO05tX4srK0MavfU+mgBZzbs9pquiIQL44UcSTQPHFvt0YgZ
dv/jpZxJSbvLNRpWM/3PxlRDC1088L1Lxo0Ele06UNlogxFcpW9Sq615EQjLPGrh
heMyb6KMp5UKqgxY9t2B+merIoOpBdzggX0CgsjYdkMRYYAmEtunVfR0hDuQLqgf
O4EdEnjUIfFu0jFl1aMrwmAgPUMGZ6b+4/u0dpy6d+1bp2qpiZbqmEEUFZRDsxxZ
YT5DavoJ1PosnkdqN1FS6rNjyyu+8v4tvPkMrYLkMJuaPolz9SYBG/12cq4vBAoj
enXFywMaUEZJZzbfa+s1vC2ATkLn5T3sKQUxm4U73N0goz3dr9P0e++OBrmBPHPC
52TpHWjiY2cT7mJ+UR7hm/mzIRYwV/DPchE8UFWZKfKHTmNki9gWpltyxRRaL3k0
KHWCxkyNSewPr4ZvUeAHd7QuZcUfDJHeHe81YHsVEWPzC9ZrSL/Lm3gRuWcJwnT3
anBKYD2mJG38L9aOlHJq
=I2Uq
-----END PGP SIGNATURE-----
--pWyiEgJYm5f9v55/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151124222346.GA91383>