From owner-freebsd-arch@freebsd.org Tue Nov 24 22:20:25 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 132CCA3714C for ; Tue, 24 Nov 2015 22:20:25 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C7261A47 for ; Tue, 24 Nov 2015 22:20:24 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: by lfaz4 with SMTP id z4so39194068lfa.0 for ; Tue, 24 Nov 2015 14:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=C0sTK7UihwiNJ0tUde022qlLlNTLmSDNFbi9DbIlOAk=; b=jmHbRbQlIT3IApLuejj/uh7clSXWE5Xm/F9tlMT+3olrShyFtcT4syH/ZnLf+OS1Ke 3otJyfOiDrLNBTWF8eMBlJ0LQHP+sY6C9B9A/QPTJqGgTa5749ABAkQDH7odQP20MktO kDA2jcIoFhg+gEY6DXXWYJXgO/onSKssH2ua7p6WOEycZuqGuv5aj+1eknmdvwKxSEwn o12QcDVrUGV9af6LCqwe5PuyJNeIvXytINbuSMZLIq7NoI0BuAAF/8GZpm67ZA8X/QED 8BEWgHjzoIOfBU3hEiE1hLSrPL3gFOvBrzYEJs6Xh8MIPtir5anKHYkSS/hkcCubBNL6 TO6g== X-Received: by 10.25.218.9 with SMTP id r9mr14484493lfg.138.1448403622623; Tue, 24 Nov 2015 14:20:22 -0800 (PST) Received: from jarvis.chello.pl (89-69-121-31.dynamic.chello.pl. [89.69.121.31]) by smtp.gmail.com with ESMTPSA id e63sm2921045lfe.5.2015.11.24.14.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2015 14:20:21 -0800 (PST) Sender: Mariusz Zaborski Date: Tue, 24 Nov 2015 23:23:46 +0100 From: Mariusz Zaborski To: freebsd-arch@freebsd.org Cc: cl-capsicum-discuss@lists.cam.ac.uk Subject: Casper new architecture. Message-ID: <20151124222346.GA91383@jarvis.chello.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 22:20:25 -0000 --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/--