Date: Wed, 25 Nov 2015 23:22:56 +0100 From: Mariusz Zaborski <oshogbo@FreeBSD.org> To: Jonathan Anderson <jonathan.anderson@mun.ca> Cc: cl-capsicum-discuss@lists.cam.ac.uk, freebsd-arch@freebsd.org Subject: Re: [capsicum] Casper new architecture. Message-ID: <20151125222256.GA18861@jarvis.whl> In-Reply-To: <F8E24931-DE20-4B75-AB36-032EE6C939AA@mun.ca> References: <20151124222346.GA91383@jarvis.chello.pl> <F8E24931-DE20-4B75-AB36-032EE6C939AA@mun.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I cc'ed arch@ one more time. In first email I was using to and Jon replay w= ent only to the capsicum group. On Tue, Nov 24, 2015 at 09:10:29PM -0330, Jonathan Anderson wrote: > On 24 Nov 2015, at 18:53, Mariusz Zaborski wrote: >=20 > > 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. >=20 > Hi Mariusz, >=20 > This sounds rather exciting, and I will be pleased to do some reading and= testing. However, possibly not in great quantities until the term ends on = 8 December. >=20 > As an initial meta-comment, might you be able to upload the patch to revi= ews.freebsd.org? Phabricator really does make it easier to read and comment= on long, complex patches like this one (I think we=E2=80=99re looking at 2= 2.5 klines?). Done: https://reviews.freebsd.org/D4277 . Thanks for advice. >=20 > > 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 limi= tation. > > 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 speci= al > > flags that will tell zygote processes to not clear file descriptors. Ri= ght > > 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. >=20 > Without reading or running the code yet, I suspect that this is a good ta= ck to take when pursuing application-level compartmentalization. Of course,= the new question becomes, can some Casper instance still service multiple = applications in, e.g., a login session? Can we interpose on messages sent f= rom an application to its libcasper to the desktop Casper to the system Cas= per (if there is such a thing any more)? I think this was the =E2=80=9CCasp= ers all the way down=E2=80=9D discussion in Cambridge a couple of years ago= =2E :) There isn't any instance of a global Casper. I remember that discussion. You suggested to mix both approach have one Cas= per in library and second one as global. For now I don't see any advantages of having them both. Not sure if I understand your example but you still can s= hare Casper process or one services. You can clone and send the Casper channel to other program, but for some services you need to remember that some things = will be inhered from original process (list above). >=20 >=20 > > I decided to remove the libcapsicum library. In my opinion Capser is > > connected with capsicum, but Casper can be used also with different san= dbox > > techniques. Now I would like to refer to it just as libcasper. >=20 > I think this sounds very sensible. >=20 >=20 > > Second change is that Casper will not execute any binary files. > > Now every services (cap_{dns,grp,etc.}) will be in form of shared libra= ry. > > 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 o= ne 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 pro= grammer > > guess where the administrator will put the Casper services. So in my op= inion 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 n= eeds to > > include some library (before just one global library, libcapsicum), so = why not > > store services inside that library? >=20 > Yes, libraries do seem to be the natural place to land when Casper pdfork= s from the application rather than starting as a system daemon. One questio= n would be whether it=E2=80=99s possible to make the Casper libraries wrap = their native counterparts such that we can replace symbols for transparent = use (e.g., keep calling gethostbyname rather than cap_gethostbyname). I'm not sure if this is possible as you presented. I think we would had a symbols collisions with libc. So when I was implementing a fileargs library (//depot/user/oshogbo/capsicum_rights2/lib/libfileargs/...) I done funny trick. Basically we would always have lib_dns.so but depending on compilation we would use or not use casper in it: int cap_gethostbyname(...) { #ifdef HAVE_LIBCAPSICUM return (casper_gethostbyname(...)); #else return (gethostbyname(...)); #endif } So our application always would use cap_gethostbyname and #ifdef would be m= oved to services. It would make application much simpler. I would love to discuss this approach at some point. >=20 > > 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. >=20 > Me too! :) >=20 > I wonder if you might be able to provide a little more discussion at the = level of how the IPC works, etc.? So what exactly interest you? I will tell you in general how it works now. Application starts. Service first register it self in libcasper thanks to library constructor (which is hidden in CREATE_SERVICE macro). Then we run cap_init() in application. Our process forks. The zygote is created and libcasper waits for commands. Then you open some service (service.dns for example). To this you use cap_service_open() function which will send nvlist whit the name of service= to Casper process. Casper process search for right functions (command function= and limit function) and pass it to zygote process. Zygote transform to be a new service. Casper send to the original process descriptor to talk with a new service. All IPC here is done using nvlist. After that you can create next service or close connection to Casper. Next you can limit your service using cap_limit_set. Its operates on nvlist. Its depending on services what you should put to this nvlist. After limiting you are using cap_*() functions which are sending commands t= o the service. Thanks for interest, Jon. Cheers, Mariusz --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWVjSyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBQ0I3NjA5RUE2Q0JEMTM5QUE5NUU2Mjg1 NDFFNzc1RTk2N0Y4OUNGAAoJEFQed16Wf4nPyI4QAMNNCPp6htDT8AbwW5w1iWNW RJMHJvdPH8GmPhJWZ8MINYW+5gD7Ib1w84m2ph9nPLN/bG/DqPCBSTyjcLD+5oXn zYi08ResDQYVPEIa9TTXi1NmpuybbIf9oDUzCnMepVvZ+YfOJtzhEMfUERY70oWW QpxR9Y1V+ktD/PHLEaOBHJ5BJGSi5Zh5si915f4t+EMg6TjxrdEt/6/wNcce1x5Z zNIBjAWZvkwDz9/OMtb9HPkPZS3HmI7iBz61W96hWn4E4mX9hB73svHipOsYvwCV rxwrkWk0/+57EUJNU1g+PYU+SuJwrXJqbip5+nr9jMByzYuWTB1jObG4io61+qjr TGkuj8NjauP0aq1bkaWGY1pU/CawKOcs7+oR9ZoI0LzgHJj4e8q1MAPBAzNOVf97 xO5V47upqbZRVDdctuXmx2ggiTdVLNGEXFJA/Ct6+m40bU2CS3NU0pdq+THIQfzj dDNbc1eEEvuXqDQYZGQF+On584YkBDqOb+HxlxJjGi3D6bC7BuUDBLjQ1BBAbcbB bxxUP96TDt6ytaHxfoUSVYiZAXG2erFxEgy2TKcg53J93YreNvtWU/LeSyGSwaiy QUztH51sL2rdBvalQxMt33/YWt6PiSepp0ZqqpGP0uuDlvfiAQRXyO7xJzvrsF9b QGbbO3tLwp4MJbvBT1sS =ISYz -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151125222256.GA18861>