Capsicum and Casper - more than a lipstick on a pig
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 24 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/15333 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produktionsjahr | 2014 | |
| Produktionsort | Ottawa, Canada |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
1
5
7
9
12
13
14
15
17
18
19
21
23
00:00
COMSystemprogrammierungKugelkappeFokalpunktRootkitMultiplikationProzess <Informatik>FreewareProgrammRechnernetzDämon <Informatik>Dichte <Stochastik>TypentheorieVisualisierungHardwareZeitzoneProgrammfehlerEindeutigkeitSystemzusammenbruchGruppenoperationSchnittmengeSystemaufrufPhysikalisches SystemGruppenkeimOperations ResearchInnerer PunktURLMIDI <Musikelektronik>Konvexe HülleGroße VereinheitlichungDedekind-SchnittMinkowski-MetrikVerzeichnisdienstOffene MengeKomponente <Software>VektorrechnungMathematikInverser LimesRuhmasseStrebeElektronische PublikationPatch <Software>Metropolitan area networkFehlermeldungKernel <Informatik>RechenwerkEmulationURNSoftware EngineeringLokales MinimumLipschitz-StetigkeitMUDStrom <Mathematik>ATMFunktion <Mathematik>Enterprise-Resource-PlanningPasswortSchreib-Lese-KopfDienst <Informatik>Familie <Mathematik>Reverse EngineeringWeb ServicesArithmetisches MittelProgrammbibliothekMaskierung <Informatik>ExponentialfunktionSCI <Informatik>Mailing-ListeModul <Datentyp>Fahne <Mathematik>OvalKreisbogenHydrostatikWort <Informatik>Inklusion <Mathematik>Total <Mathematik>DefaultMicrosoft dot netLie-GruppeDatenmodellDifferenteTabelleBefehlsprozessorStatechartEindringerkennungComputerunterstützte ÜbersetzungDämon <Informatik>VerzeichnisdienstProzess <Informatik>Physikalisches SystemRootkitElektronische PublikationFunktion <Mathematik>StandardabweichungGruppenoperationMathematikSchreib-Lese-KopfSystemaufrufInverser LimesWeb ServicesMAPApp <Programm>MultiplikationsoperatorKonfiguration <Informatik>Mechanismus-Design-TheorieMailing-ListeOffene MengeSchnittmengeKartesische KoordinatenSystemzusammenbruchTabelleNichtlinearer OperatorRechter WinkelBitInterface <Schaltung>Patch <Software>ProgrammierungDateiverwaltungATMDienst <Informatik>StrömungsrichtungEndliche ModelltheorieProgrammfehlerKernel <Informatik>KugelkappeFehlermeldungEinfach zusammenhängender RaumMehrplatzsystemProgrammbibliothekNetzbetriebssystemGemeinsamer SpeicherComputersicherheitVirtuelle MaschineFunktionalNetzadresseVersionsverwaltungGüte der AnpassungFensterfunktionNotebook-ComputerDifferenteEreignishorizontProfil <Aerodynamik>Reelle ZahlZahlenbereichFahne <Mathematik>HackerEinsCoxeter-GruppeNamensraumOrdnung <Mathematik>QuellcodeEigentliche Abbildungt-TestObjekt <Kategorie>E-MailClientSoundverarbeitungHilfesystemVerschiebungsoperatorEindringerkennungSpeicherabzugCodeCASE <Informatik>BinärcodeTypentheorieHardwareVirtualisierungVariableInternetworkingTropfenNormalvektorVerknüpfungsgliedSocket-SchnittstelleDomain <Netzwerk>Einfache GenauigkeitAutorisierungRoutingSimulationInhalt <Mathematik>VarianzHyperbelverfahrenVerschlingungFreewareTouchscreenMereologieQuaderKryptologieDatenstrukturFlash-SpeicherÜberlagerung <Mathematik>DämpfungFokalpunktSemaphorGraphische BenutzeroberflächeSoftwareentwicklerRPCDeskriptive StatistikAdressraumProtokoll <Datenverarbeitungssystem>MakrobefehlGrenzschichtablösungGamecontrollerSocketTopologieStatistikAttributierte GrammatikDefaultService providerDirekte numerische SimulationTranslation <Mathematik>RandomisierungInformationExogene VariableSubstitutionPasswortParametersystemRandwertGeradeEinfügungsdämpfungVerband <Mathematik>Gerichteter GraphPhysikalischer EffektTeilmengeMinkowski-MetrikWellenpaketGesetz <Physik>PhysikalismusRichtungLesen <Datenverarbeitung>ProgrammiergerätEinflussgrößeSchlussregelUnrundheitPunktTrennschärfe <Statistik>Bus <Informatik>AggregatzustandSichtenkonzeptSoftwaretestDatensatzHalbleiterspeicherFaktor <Algebra>Automatische HandlungsplanungMehrwertnetzArithmetisches MittelAuswahlaxiomComputerspielFamilie <Mathematik>Mini-DiscOktaederDreiecksfreier GraphMetropolitan area networkVollständiger VerbandLeckWald <Graphentheorie>MinimumSondierungWhiteboardQuick-SortMobiles InternetDatenflussPrimidealWort <Informatik>BildschirmmaskeHill-DifferentialgleichungWasserdampftafelWorkstation <Musikinstrument>Total <Mathematik>GrundraumResultanteGewicht <Ausgleichsrechnung>MatchingBetragsflächeCodierungKontrollstrukturSchnitt <Mathematik>SkriptspracheSuite <Programmpaket>Prinzip der gleichmäßigen BeschränktheitFitnessfunktionRechenschieberFormation <Mathematik>DiffusorComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
microphones as we speak. Okay. So the presentation is about Capsicum and Casper and how Capsicum and Casper help to avoid using hacks that are currently used to sandbox applications. So before we start, let me introduce
00:24
Mariusz first. Mariusz was a Google Summer of Code student who was working on the Capsicum, a successful student, and is now working with me. And my name is Paweł.
00:43
I work at Wilt Systems. We do security products, and I also free business committer for more than 10 years now. So why we decided for the title and why we, how we came up with the talk idea in the first place.
01:03
So this is the mailing list that basically talks about capabilities, object capabilities. And a question was sent there. What does people think? What do people think about Capsicum?
01:21
Is it just a lipstick, lipstick on a pig, or maybe it's the solution. So we accepted the challenge and some history.
01:40
The biggest problem with the operating systems we have now, be it Unixes or Windows, is that both those systems were actually designed with more taking care of separating users
02:01
between themselves. So Unix, even Multics, was designed as multi-user system from the start. Then came Windows NT and Windows NT 4.0, I think was the first multi-user Windows version.
02:20
Truly multi-user because of course we had Windows versions before, which provide some kind of separation, but it was not really for security. You just had different profiles. And of course, Mac OS X was based on FreeBSD. So it was also prepared to be multi-user operating system,
02:43
but there was no real isolation between users' processes. So there was strong focus to actually protect setUID's programs. So basically programs that elevate their privileges when you
03:02
execute them, like passwd or tools like that, that required to access, to root, to root readable files. And of course there was a strong focus to make the network daemon secure. So your machine cannot be hacked remotely,
03:25
but nobody really cared about making PDAF reader secure or making all the tools that doesn't require setUID bit or are not networked daemons. Nobody cared about security because you cannot switch to different
03:44
user or you cannot attack the machine remotely. It's not really true, but that was the idea. So what types of isolations do we have? Nothing new.
04:00
We have hardware virtualization like Beehive, Zen, VMware VirtualBox. We also have operating system level virtualization like jail zones, Solaris zones, OpenVZ on Linux. And we have process sandboxing, Seedbelt from macOS 10, SecCom from Linux and Capsicum.
04:28
So I'm sure you all saw this picture already, but does this pretty much summarize the shift in how we see security,
04:42
how we what we are trying to actually protect, because of course protecting root user on your laptop is not really good goal because root doesn't really has any meaning. And if someone is able to gain access to your account,
05:04
I'm sure he will be able to skip to root. So do we really need this process isolation? We had a few weeks ago,
05:22
we had a security event. My company is organizing a security event in Warsaw in the evening. We just invite people, whoever is interested in security just comes in the evening and have some fun. So we, we invited Grinval Kolduyn to
05:41
wheel evening to give a talk. He's from Google security team and stuff like they do is, for example, in this period, they were able to, by fusing, they were able to find, or at least that 1120 bugs were fixed in FFmpeg
06:05
not sure how many wasn't fixed yet, but even the fixes the FFmpeg developers did introduced new bugs, new crashes. It was a long process and I'm sure it's far from being finished. And this was only by fusing. It's, it wasn't really
06:24
security audit of the code. The same for flash or Adobe reader. basically tools like that have many bugs. Nobody cared about them and still many doesn't care about them.
06:40
And I would like to show you how techniques that are currently used are not really feasible to address those problems because most of the hacks we use to secure those applications actually require root access. You have to be root to be able to change root or change your UID. And I would be really,
07:03
I wouldn't sleep well if I could, if I would set UID to root to my FFmpeg utility, that wouldn't be a good idea. Okay. But let's try to go through all those, I call them hacks.
07:21
You can call them portable sandboxing techniques if you want. So the, widely used technique was to just drop the credentials and almost every tool does use some kind of sandboxing change their credentials, right? For example,
07:44
open SSH default sandbox mechanism does just that. It use unprivileged SSH user. But
08:00
why is it hard to actually use that because it's very error prone. All those techniques are, were not really designed to provide sandboxing. They are used because you can find them on almost every single operating system, but, or at least Unix like operating system.
08:22
But you have some things to remember about, for example, when you change your UID, you have to change your group ID as well. But when you change your group ID, you have to do it before you change your user ID. Because of course, once you change your user ID, you have no longer permission to change your group ID.
08:44
And when changing your group ID, you have to remember that there can be much more groups that you should drop before actually changing user ID and group ID.
09:03
That's the order I said about. Also you have to verify that all those operations actually succeed because there are many problems with that. We had really nice send mail security back where Linux introduced POSIX capabilities, which are not capabilities.
09:24
It's just the name, but those are not really capabilities, just some privileges, global privileges. There was a back in sendmail where sendmail didn't really check if setUID succeed. So when sendmail didn't have this permission or privilege to change his
09:43
own user ID, it was trying to drop privileges because it was running as root, but this operation failed. So sendmail was running as root without actually dropping any privileges. So you have to verify if it succeeds. Another problem you can have,
10:03
so resource limits, for example, this user cannot create more than that many processes. So if you try to change your user ID, you may hit resource limits. And of course, I'm not really sure, but that's suspicion that not
10:24
on all operating systems setUID modifies all those real effective and safe user ID and user group. And of course the biggest issue is that it requires to be root.
10:49
So this is basically what I think the code should look like and it should be secure, I think, in that order. So we drop all the groups,
11:01
we set a group ID, we set user ID, we verify all those operations and just to be sure we verify them again. Change root, another way to sandbox your applications. So basically change root just restricts access to the directory
11:23
you gave to the system call. For example, open SSH use change root to change root to a slash var slash empty directory, which has no content. The unprivileged process cannot write to it. And it should be pretty safe, but
11:47
of course, change root requires root. Once you change your root directory, you have to remember to change your current working directory
12:00
to new root directory. If you don't do that, you can still access files outside of your new root. And of course, another problem, if you will leave directory descriptors behind, you can use F change D to actually escape from your change root.
12:25
Another problem is that all the path components from the root path you are trying to change to should be owned by root. If user can write to those directory,
12:42
he can rename the directory. He can create a sim link and you can change it to some different directory than you hope it for. So this is also very important. And of course you have to check for change root and change your failures. And actually doing this first bit,
13:01
a race free is also pretty challenging. It's not really easy to verify all the path components and be sure that you are changed rooting to the same directory that you have actually verified if there is no race between.
13:24
So this is the code that implements that, although I skipped those two bits at the top because the code would be just too large to fit on the screen. And of course checking for open directories is very expensive. If you have to scan all the descriptors that can be used,
13:44
the same for ownership, it's really tricky to do it right, but, and also pretty expensive. Set a limit. This is nice hack. It's used as far as I know.
14:00
I know only about open SSH using this to implement some kind of sandboxing. So when you limit your number of descriptors to zero, you won't be able to make internet connections anymore,
14:20
open any files and stuff like that. So it's a really nifty trick. You can also limit file size and this allow forking by limiting number of process to zero. But it's not really widely used because I think it's very impractical to not be able to do any kind of descriptor operations that you cannot
14:44
duplicate your descriptor, you cannot receive descriptor that someone delegates to you. So it's very limiting. That's why I think it's not really widely used. Nice thing about that is that it doesn't require root access. It doesn't require root. There is also in kernel,
15:01
you have this p-understore sugit flag which is set by the kernel. When you do set UID or when you execute set UID binary, and it can restrict the various interesting things. For example, open SSH sandboxing drops privileges to SSH user.
15:23
But every single session in the system, every single SSH session, sandbox is running as the same user. So in theory, if I break to the sandbox, I can then use ptrace to jump to another sandbox
15:42
because it's run by the same user. But because of this flag, it's not possible. So this is also a nice hack and also it restricts various signals. So I cannot send all the signals to different process that has this flag.
16:00
I can only send some subset of signals, hopefully secure subset. And there are, here are some proofs. So we had a bug where there were missing checks for set UID or set gate or set groups.
16:23
Someone forgot to check about them and it was a security bug. There was no set group call. So actually someone left all the groups owned by to which a root user was the member of. Someone was leaving those behind,
16:42
which allowed to do some interesting things. And someone called set UID instead of set UID, set EUID. So this one only changes effective user ID. And if you change effective user ID in Unix,
17:03
you still have safe user ID. So you can easily get back to your root privilege by calling set UID with basically with zero. Set UID is not really used to change all the IDs.
17:21
It's just to change your effective user ID. So when you create a file, this file is owned by this effective user ID, but you can switch back to your previous UID, which is in this case root. Change root.
17:45
There were a few bugs when people forgot to change their root after calling change root. There was one bug we found with where change directory was readable by the user.
18:02
So you can do things like, you can link setuid binary to your change root and then create your own, for example, libc that will be loaded when you execute your set UID binary. And of course, once you have root access,
18:20
you can escape your change root easily. There was a bug, I think in NetBSD, where this flag was not properly checked and ptrace was allowed, even if the process had this flag. So it's not really application bug,
18:42
but it's worth to know that those sandbox techniques require this to work. We didn't found any bugs with set and limit, but I think it's mostly because only very small number
19:02
of programs actually use that because it's very limiting. So maybe that's why, and maybe we weren't looking properly. And for example, this is a patch that was proposed to fix this missing change dir. And it is wrong because ignoring the fact that
19:22
nobody checks all the path components, the change dir is done, the change dir is done before changing root. So here this directory can be changed. So actually you can change dir to a totally different directory than you change root then to. I don't think it was commit,
19:44
or at least it was fixed because we checked cyslocng source and it's better now. But even order of those operations is pretty important. Okay. In capability world,
20:03
you don't have access to global namespaces. And in FreeBSD, you have quite a few of them. Can you see actually the text here? Somebody knows how to turn on the lights.
20:23
Okay. And we have all those techniques and we will see which ones actually protect against accessing the various namespaces. So for example, you have process IDs, set uid or change root won't help.
20:44
Set psugit does help a bit that it in a way that it restricts a number of signals you can send to the process, but you can of course always list all the processes in the
21:01
system. So if you will break to OpenSSH sandbox, for example, and someone is using a tool that takes password as an argument, you can list process names and all the arguments and actually get the password. Of course, it's not really great idea to do that,
21:22
but people does that. So file paths, that's of course, file systems. So change root helps here. Set uid helps in a way that you cannot access root owned file systems and files and stuff like that. And set limit
21:43
does help a bit because you won't be able to open because you cannot create new descriptors, although you still can list directory content and stuff like that. NFS file handles, set uid helps here because you have to be root to actually be able to convert or open file by NFS file handle.
22:04
But even if you are change root, if you change your root, you can still open files outside your root if you are a root user. File system IDs, those are basically returned by system calls
22:22
like get FS stat. You have this file system ID returned only for root. So if you drop your credential privileges, you won't get those. Sys controls, some of the set uid helps at least,
22:44
well, helps a lot, but it doesn't protect entire Sys control trees because there are still Sys controls that can be written by everyone or all Sys controls can be read by anyone. So it doesn't cover all the cases.
23:02
And psugid flag helps because, for example, there are system calls that allow to change, for example, resource limits of processes with the same user ID, although they do check if the process doesn't have this flag. So it also helps, but it doesn't cover all the cases.
23:24
System 5 IPC is not protected by any of those. So if you have a shared memory or semaphores using system IPC, there is no protection using those techniques. POSIX IPC,
23:42
there is some protection when you drop your privileges, but the best one, of course, is just disallowing creation of new file descriptors. System clocks, you can, of course, read time, but you won't be able to modify system time if you are not root.
24:03
For jails, this namespace is about jails IDs and stuff like that. So you can still list available jails in the system. You won't be able to attach to a jail and do stuff like that if you are not root. CPU sets, it's not really important namespace,
24:22
but nothing protects about messing with it. The same for routing tables. You can just change your routing table if you want to. There is no checks, no security checks at all. Prok protocol addresses.
24:41
This is about doing IP connections and also using Unix domain sockets for connections. So change root does help when you, so you cannot connect to Unix domain sockets, but it doesn't help when you want to,
25:02
when you just want to be a part of, I know, spam botnet. For example, in FreeBSD, we did use this error limit, set error limit, but I don't think we use it anymore. Is there this around? We don't use error limit anymore, right?
25:21
On the FreeBSD, in SSH sandbox, we use Capsicum now. It does, or? Because I remember that we weren't able to use set error limit because we were using open crypto. Yes.
25:52
When we use crypto acceleration, it does require to planning another file descriptor. So we weren't using, weren't able to use set error limit before Capsicum,
26:03
which means that if my only goal is not to hack into your system, but just to create another box that will send spam for me, that's fine by me. I can break into your SSH sandbox. If I can break it to your SSH sandbox, I'm able to send spam. So that's fine by some. In practice,
26:26
we can protect those two namespaces correctly, because as I said, set error limit is pretty much impractical. So not many programs use that. So this is more or less how it, how it works with current techniques that are used
26:44
for sandboxing. Enter Capsicum. So Capsicum basically provides two things. One is tight sandboxing.
27:01
CapEnter allows you to enter capability mode where you have no access to any global namespaces. You cannot open files. You cannot do internet connections. All the rights or authorities you have are either inherited or delegated to you through Unix domain sockets.
27:23
And another one is capability rights where you can limit your file descriptors to only some basic functionality. For example, if you open a file, even for read only, you can still change ownership, change the file mode and do stuff like that. You can use capability rights to actually limit a file you open to only,
27:44
to do only reads or only writes. We won't talk about that, but we will talk about sandboxing some more. So this is our table from before. I'm not sure if you expected that,
28:00
but with Capsicum, it looks much better. We can protect against accessing all those namespaces. And there is no question marks in here. So if you compare the code you have to write to sandbox using those techniques I talked about,
28:25
it's pretty complex. And again, I'm not even, I wasn't even trying to implement checking ownership of all the paths when you change route or looking for open directory descriptors. So it's much simpler than it should be.
28:43
And you can replace all that with one cap enter call and you get much more. So I think it's pretty nice. So current Capsicum usage in base.
29:02
We have a DH client already using Capsicum has to D has CTL, RFU D, RFU who was sandboxed by Mariusz during Google summer of code. We sandboxed unique out of this D of course, SSH D also now uses Capsicum sandbox.
29:21
We also have TCP dump, K dump and ping. And we are working on more and we are of course, ready, welcome, any patches welcome, I would say. So if you would like to sandbox some of the tools in the system, it should be pretty easy, I think.
29:46
Okay. So Casper, I will switch to Mariusz. So before I start, I just want to say that this is my first conference and
30:06
it's my first presentation in English, so I'm pretty nervous, so please don't throw any comments. So help me welcome Mariusz. So, Casper, as everybody knows, it's a trendy house but in FreeBSD, it's a demo
30:33
that provides us some functionality that it's not allowed in CAPT mode, CAPT opening as well.
30:43
So we try to make the apps of the functions that are provided by Casper, very similar to the original functions.
31:02
So we have some services in Casper, every those services are response for some other functions, like service system DNS is providing us some functions to get the cost or get address information.
31:26
And like you see, we have services like system file or system random and all the services can be also limited by programs.
31:44
So we could, in some case, we could limit the system DNS to be able to only resolve some specific type of address.
32:21
So here is an example of using Casper. We have a function to init Casper, it's a function that connects to the Casper demo. We then using CASP service open to open the special services that we would like.
32:50
Next we limit those services to only use boundaries of address and here we have usage of the Casper functions.
33:13
We need to use that macro because we don't know if the system is installed with the Casper demo on its own head.
33:27
So we need to use this even more often than it was seen provided because we must check before including headers, before creating the connection with the Casper and so on and so on.
33:53
Ok, so here we have some programs that use Casper. It's TCP DAMP, DAMP, and PIMP.
34:02
We could standard those applications but only with some options that they are provided. For example, with TCP DAMP we will be able to use IP translation because, like we said before, we are able to enter to any namespaces.
34:34
So TCP DAMP will only work with the HANA options and CASPER will only work
34:43
with error options because we would not be able to translate the GUI to the text.
35:06
After a while we also develop system file card services which allow you to sandbox programs which takes a list of file card programs.
35:28
Before we don't have any service that was provided that has some files, so system file card is not only the Casper services but it's also a library.
35:48
It's the first approach which we made to delete this every step in our program.
36:04
System file card is divided into two separate modes. One is provided as sandbox functions and another one is provided as unprotected functions.
36:25
So in sandbox mode we use Casper to provide us descriptions but in unprotected mode we just use the open function. It's one app to get it, so we are able to remove, we don't need to check which version we need to use.
36:52
And it's still not committed yet and I will say in a little bit later why.
37:02
Ok, so here is the app that we provided, the system file card. So we have one function to delete and to leave the library. The second one is just checking if Casper is running and if we should enter to a capability mode.
37:24
Another two are just remakes of open and, sorry, the one is only the remakes of open function and the last one is just to clear the structure.
37:42
So I'd like to show you how we sandbox UC program in three steps. The first one was to add two headers. One was Sys capability which provides all the Casper functions.
38:02
And the second one was our file card header. And we also added a global file card variable. It's normal because the deal with changing the interface of the booksend was a little bit longer but still not complicated.
38:29
So the next step is just to delete the file card's library. So we leave RFC and RFBAL and define what rights it should be open.
38:48
Then we check if the library was incorrect. And then we check if we're using unprotected mode or sandboxed mode.
39:03
If we use a Casper then we just enter to a capability mode. And the last step was just to change open function to file cards open.
39:20
So as you can see that was very easy to do. So we also have some problems with the current model of Casper. We didn't mention that, but Casper is a demon that has found a special process called ZIGALPAT which then is an exact function.
39:53
And it became a service that we wanted. So Casper is running as root because he needs some additional capabilities.
40:08
So the third problem was different credentials. Casper is running as root and the process that is asking for some operations is run by the user.
40:21
So for example in file cards we would allow to run services in as the root. We have access to all files. So we bypass the standard file cards.
40:42
So we were able to refer this problem by using functions like SEPUI and SEPUI as a root.
41:01
So now the services run the same write like the problem that is asking for. Another one is that we brought different resource limits. So like Paolo mentioned before, we have functions like Elwing which sets some limits on the process.
41:24
And we don't have any mechanism which allows us to get those recent limits and to set them to the Casper service.
41:40
So we have this problem that Casper has more limits. It doesn't have any limits. And our process could have some limits. Another problem is about different working directory. It also was connected to the file card service.
42:01
If we would like to open some files using only the relative path, the Casper service is open in a different directory than the system file card. So we must somehow provide Casper the information about in which directory we are working.
42:30
So we must manage to do this by sending the correct directory to Casper when we open the service.
42:42
We send it as the file descriptor because if we send it as the text, there will be a raise that the directory could be deleted or some options of the directory could be changed.
43:04
We also have a problem with different humans. The Casper daemon was running as root. So it takes the humans from the root user and the user that is running the process could have different humans.
43:30
So this was easy to buy us by sending every time if we send the file with how to create one.
43:44
Then we also send humans to the Casper. Another problem which we were unable to solve is the different map levels that the root user has and the user that runs the process.
44:15
We also discovered that we have a problem with different routing tables.
44:23
You can set the routing table using setPit function and set a routing table for only this one process. So we also don't have any mechanism to send the current routing table to the Casper.
44:44
Another one is that we have different support sets and we also don't have any mechanism to do this. We also discovered with system file parts that if we use dept and dept or dept and dept files, it won't work.
45:12
Because Casper has a different file district of the program which is run. We could see here the example where we are using a particular substitution in a dept program.
45:32
The first line of the dept output is that the file is dept. So when we are using the process substitution, we receive the dept.
45:50
If we try to open it, it is the same as if we try to duplicate the description.
46:03
Here is also the problem that we cannot resolve. We also have a different process group and a different in-group. We also have, because of using the multi-process and the processes running by a different user and so on,
46:26
it is harder to audit or cut with the open mode program. Ok, so just to make it clear, can you hear me? Does it work? How about now?
47:00
Just to make it clear, we are able to securely send credentials to the Casper daemon,
47:07
current process credential, because Unix domain socket is allowed to do that. But we cannot securely send any other stuff like current working directory or mandatory access control labels or UMAS because it can be forced.
47:24
We would have to send it as data and of course the sandbox could send whatever it wants to send. So the future goals we are looking at is to eliminate this problem, this separation that the service process is formed by the Casper daemon
47:46
by just moving from a daemon model to more library model, where basically you just initialize Casper library, not a daemon when you start and then all the service processes will be children of the process itself.
48:05
There will be no separate daemon. So it will inherit all the attributes of the original process, like working directory, UMASK, mandatory access control labels. It will be easier to audit or k-trace such process.
48:24
And of course we are looking how to lower the bar for new Casper customers. Of course Casper itself is a way to lower the limit because in capability mode you cannot access global namespaces, so basically what Casper does is to provide you
48:41
a way to access the global namespaces in a restricted manner. In this TCP dump case we were limiting system DNS service only to answer to reverse hostname lookups, so you can only translate IP addresses to hostnames,
49:03
not the other way around. Another way to lower the bar is Mario's system file arcs, where we use one API and there are no if-defs. You just use the same API. Either you have Capsicum or Casper or not.
49:24
You have just the same API and it will discover if you actually can sandbox or not and it will either open files directly or will open them through this Casper service. So I think that's all we had for today.
49:49
Are there any questions? Close your eyes. Yes. You mean by trying to protect the debugging applications?
50:19
Well, kdump is a case of a debug application that we did sandbox,
50:26
just to be sure, because for example if you are a FreeBSD developer and you receive ktrace output, I would prefer to analyze it in sandbox, not directly, so we did do that, of course.
50:44
There are much more tools like that to sandbox, but of course we are welcome to commit any patches you have. Any other questions? Yes?
51:09
Can you tap this on the back? I don't know.
51:32
Yes, actually the sandbox limit that is also in OpenSSH doesn't allow to even create new descriptors,
51:40
so the sandbox itself probably is not the process that is going to interact with stuff like that. If Capsicum is not portable, right? The question is if Capsicum is portable. Of course we are fighting for Capsicum to be portable
52:01
by trying to prove that that's the way to do stuff, and there is ongoing port to Linux sponsored by Google, so Google is porting Capsicum to Linux, so hopefully from what I heard, OpenBSD also likes the design,
52:22
so hopefully Capsicum will be ported to OpenBSD as well, and others will follow, hopefully, and finally we will have portable Capsicum, which basically we can use instead all of those nifty tricks.
52:47
Any other questions? Okay, thank you very much.