Building a security appliance based on FreeBSD
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 34 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45155 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
1
2
3
4
7
8
10
14
15
17
18
22
23
26
28
31
32
34
00:00
Document management systemBuildingInformation securityBitInformation securityMusical ensembleIntegrated development environmentFile systemKey (cryptography)Right angleBootingSoftware developerOperator (mathematics)Assembly languageEncryptionStandard deviationStatisticsData storage devicePower (physics)CuboidNumbering schemeBoss CorporationProcess (computing)SoftwarePairwise comparisonFormal verificationCondition numberMereologyDemo (music)RoutingMultiplication signVector spaceRevision controlINTEGRALGroup actionAuthorizationOverhead (computing)Configuration spaceCryptographyGraph coloringSpacetimeMatrix (mathematics)AlgorithmFlow separationVirtual machineDatabaseBefehlsprozessorBlogDifferent (Kate Ryan album)Physical systemTrailComputer hardwareInclusion mapOffice suiteMetadataCountingData centerSoftware bugTable (information)Point (geometry)AdditionCodeMicrocontrollerInternet service providerMiniDiscWritingPrinciple of maximum entropyBinary codeComputer configurationJava appletRootProduct (business)VirtualizationComputer fileComputer animation
10:03
Document management systemInformation securityBuildingMiniDiscStaff (military)Multiplication signInformationBackupInformation securityRevision controlVirtual machineAxiom of choiceData storage deviceData compressionProteinCASE <Informatik>Core dumpThetafunktionCategory of beingEncryptionType theoryNeuroinformatikFile systemBinary codeSpacetimeBitMultiplicationDemo (music)Block (periodic table)Product (business)Computer configurationPoint (geometry)Overhead (computing)Computer networkFeasibility studyAdditionClient (computing)MathematicsSemiconductor memoryBand matrixBookmark (World Wide Web)Moving averageGoodness of fitComplex systemControl flowSet (mathematics)Roundness (object)DatabaseCartesian coordinate systemComputer programmingImage resolutionRollback (data management)Computer fileBootingNumberFactory (trading post)Standard deviationComputer animation
19:31
Document management systemInformation securityBuildingFlagVirtual machineOnline helpDatabaseCASE <Informatik>Read-only memoryPhysical systemOffice suiteTowerMoment (mathematics)Right angleAuthorizationFile systemGoodness of fitPoint (geometry)Partition (number theory)AdditionDifferent (Kate Ryan album)Arithmetic meanData storage deviceContext awarenessWritingEncryptionBootingKey (cryptography)Information securityHidden Markov modelDemonMiniDiscAuditory maskingOperating systemMathematicsScripting languageClient (computing)Computer networkPasswordException handlingJava appletProcess (computing)Form (programming)Volume (thermodynamics)Computer configurationMultiplication signCurvatureAttribute grammarRevision controlMultiplicationInternet service providerAxiom of choiceBitOrientation (vector space)Block (periodic table)DataflowFood energyInstance (computer science)Factory (trading post)Control flowStorage area networkObservational studyGame controlleriSCSIFlow separationError messageRollback (data management)Database normalizationRemote procedure callParity (mathematics)SpacetimeTable (information)Computer animation
28:59
Document management systemBuildingInformation securityDemo (music)Process (computing)DampingComputer networkInformation securityProxy serverHash functionKey (cryptography)Multiplication signBuildingType theoryConnected spacePasswordGoogolAuthenticationCartesian coordinate systemCASE <Informatik>RandomizationArithmetic meanSingle-precision floating-point formatCodeOpen sourceComputer fileLogicVirtual machineBefehlsprozessorResultantDifferent (Kate Ryan album)Goodness of fitKeyboard shortcutLibrary (computing)Sampling (statistics)Source codeNamespaceLengthData storage deviceTelecommunicationBitPrimitive (album)DatabaseSystem callFlow separationDemonCommunications protocolRankingFerry CorstenSpacetimeInterprozesskommunikationPower (physics)Formal languageRight angleExtreme programmingMessage passingInternet service providerComputer animation
38:28
Document management systemBuildingInformation securityProcess (computing)Connected spaceHash functionSoftwareComputer filePoint cloudData storage deviceLimit (category theory)Computer networkBitFormal languageSoftware developerMultiplication signCartesian coordinate systemInterprozesskommunikationPhysical systemKey (cryptography)Data managementSlide ruleMoment (mathematics)Client (computing)Office suiteAdditionIntegrated development environmentPartition (number theory)BootingType theoryInformation securityMobile appBefehlsprozessorPasswordCommunications protocolMusical ensembleRankingDampingQueue (abstract data type)Form (programming)MereologyCrash (computing)Server (computing)WordRight angleLogic gateLevel (video gaming)1 (number)Canadian Mathematical SocietyComputer programmingCache (computing)Connectivity (graph theory)Virtual machineGame theoryPower (physics)CountingComputer animation
47:56
Computer animation
Transcript: English(auto-generated)
00:12
So, welcome everybody. Today I will tell you a little bit about building a security appliance based on FreeBSD.
00:21
When we look into the market, there is no many FreeBSD-based appliances. Come on, why are you doing that to me?
00:44
Okay. Nobody in breath now. So, if you look into the appliance market, there is no many appliances based on the FreeBSD. If you look into the market of the security appliances, there is the statistic that goes even worse.
01:10
So, my name is Mariusz Zaborski and I'm working for Fuda Security where we are building an appliance based on FreeBSD.
01:21
In my spare time, I'm also a FreeBSD committer. I'm also creating a Polish BSD user group. And sometimes I'm also blogging, so if you would like to read a little bit more about my work, you can visit my blog as well. So, today we will try to build a box similar to this one.
01:42
Nice, black-red box. We will not focus on the hardware part, we will focus only on the software part. So, we will start with the data encryption because when we are talking about the security of the appliance, the most important thing is the data stored by our customers.
02:03
So, we will be talking about data encryption, how we can protect the customer data. Another thing will be storage. How we configure it, which file system we are using, how does this configuration allow us to do a secure upgrade of our product.
02:22
Another part will be external storage because it doesn't matter how many disks you will provide for your customers. It will be 20 terabytes, 30 terabytes, there always will be customers for which this isn't enough space. Another thing is the remote access. So, sometimes, not often something goes wrong and we need to go and check what is wrong.
02:47
Maybe we need to pick some data, maybe we need to check some database tables and so on and so on. So, how our support department will connect to our box.
03:00
And the last, but not the least, we will be talking about the process security. So, how we build an environment in which we can minimize the vector attacks in our appliance. So, like I mentioned, we will start with the data encryption, which is kind of one of the most important things.
03:20
So, we want to encrypt our data, so if somebody would take our disks from the appliance, he can't get to the data without the authorization. So, in FreeBSD, we have three different encryption methods. To be honest, we have two because native CFS encryption is still not available. And also, there are some downsides with the native CFS encryption because not everything is encrypted with CFS.
03:50
Data are, but some of the mega data of the dataset are not. And we want to encrypt everything. We want to do all this encryption. So, we end up with GBD and with Java.
04:03
GBD is the oldest method to encrypt the dataset data. It's with us from FreeBSD 5.0. It supports only one encryption method. It's ISCBC. It's a interesting technology because for every drive, there is additional random key, which we also need to store.
04:30
This key is used to encrypt our data. This introduces two overheads. We need the CPU overhead because we need to generate this key.
04:41
And this is the overhead because for every drive, we need to store also this key for which this data was encrypted. So, anybody else still using GBD? Is there anybody who uses GBD? Yeah, nobody uses GBD because it's kind of old technology.
05:00
It's not developed anymore in FreeBSD. And this is because we have Java. Java is a more standard version of encryption. It allows us to encrypt data with many different cryptographic algorithms. The most popular is ISXS, which you probably should use as well.
05:22
It doesn't introduce any overheads like GBD. So, it doesn't do this fancy thing with additional keys per write. And it also allows us to use one-time keys, which allow us to encrypt our swap with a key which is generated during every boot.
05:47
It also allows us to do integrity verification with HMAC. This is an additional option for GLE. We don't really care about that so much because finally we will use ZFS. And I will tell you a little bit more why we don't use this integrity.
06:06
So, if we are building this appliance, where are we keeping those secrets, the keys? So, when the customer will get our appliance, there is no encrypted data yet on the appliance itself.
06:22
So, during the first boot, the appliance will ask the customer to put two mem sticks to the appliance. During that, the encryption keys will be generated. So we, as an appliance provider, don't know the secret which was used to encrypt the storage.
06:46
So, after that, the customer removes the pen drives, it's saved or whatever, and puts it only when he needs to reboot the machine. Some customers decide they trust their data center, so leave the pen drives and mem sticks in the box.
07:07
But yeah, it's up to them. So, with the virtual machine, there is no such thing like mem stick. We will get an encrypted virtual disk and mem stick, which is also a file, so this doesn't make sense.
07:23
So, with GLE, we can just use pathways for this or configure our appliance without any encryption. So, we decided to use GLE because this is our obvious choice for us. GLE isn't as much developed as it was in the past, and GLE is a new technology that we want to use.
07:44
So, what about the storage? Where do we store our data? So, in FreeBSD, we have two major file systems, ZFS and UFS, and we decided to use both in a little bit different ways. So, I will tell you a little bit about the advantages of ZFS when we decided to use it.
08:06
Those are four of them. Of course, ZFS has a lot of more advantages over other systems, but those are four major that we are caring about in our appliance. So, checksumming. ZFS allows us to use five different checksums.
08:24
What is interesting in ZFS is also not only checksum the data, but also checksum the metadata of our data set. So, I always talk why the checksum is very important. So, when I'm talking about reproducible builds or when I'm talking about ZFS, I love this example.
08:45
This is a sneak code from OpenSSH. This was a bug a few years ago. As you can see, there was a bug comparison operator here. So, the idea is some ID channel, and allocated channel is how many channels are allocated.
09:03
If this condition was true, then we executed something as a root. The thing is pretty much simple, because basically we changed the comparison by one bug. So, if you look very closely to the assembly code, it turns out that there is only one assembly code instruction,
09:28
which separates us from the secure and unsecure binary. If you look even closer, it turns out that it's one byte a bit, which separates us from the secure and unsecure binary.
09:48
Alan Jute has his favorite quote, which is that these are plotting against you, and this is why you should use ZFS. The truth is that everything is plotting against you.
10:01
Your CPU is plotting against you, your microcontroller is plotting against you, your cables are plotting against you. On every disk step, there may be some bit-flip. Of course, this is a very rare situation, but it can occur. If it occurs in such a situation, then we have an unsecure binary.
10:22
So, we want our data to be checksum. Another interesting feature of ZFS is compression. Right now, we have two versions of compression, gzip-lz4.
10:41
This standard is still on the way, but we decided to use lz4, because it has a good ratio between compression and decompression data. Maybe in Europe, gzip will be a little bit better.
11:00
We have an example from our production machine, and we get almost over 16 ratios of compression. This means we store 16 more times data that we can store. It also means that we optimize the bandwidth between storage and application.
11:23
If we compress data before storing it, it also means that we need to send less data to disk. So, it's very interesting. The only problem, which you may have cured here, is that what if your customer wants to send data out of the appliance?
11:42
We had such a situation that our appliance said, Oh, you are using only two terabytes of this, and then our customer said, Okay, so I will do a backup, and he needs 20 terabytes of storage. He was very surprised. What is happening here? So, yeah, but it may convince him also to use the SM program. It's solved.
12:05
Can I ask a quick question? Yeah, sure. So, where is the encryption happening before you compress your app? Before, first it's compression, and then it's encryption. Oh, encryption. Yeah, because I was going to say, you're doing 16X on encryption.
12:25
No, no, no. So, I will show later... So, 16X is before encryption. Yes, yes, yes. I will show a little bit later how cold disks are configured. So, maybe this will be a little bit more undisturbed. So, another interesting feature is snapshotting.
12:44
Matt Harris did a whole talk about snapshotting, so I will only say that it's a very interesting technology. We use it for upgrading machine. So, before every upgrade, we create a snapshot, we play with our database, we play with our file system,
13:01
and if something goes wrong, we just roll back and everything is fine. You also may use snapshotting for administrative purpose. So, if you're an engineer and want to do some stuff, but he isn't sure about using some comments or playing with data, basically you can create a snapshot and play without any risk of losing data.
13:26
Also, we are using snapshot to create a cluster multi-master, which means that in our appliance you can have two nodes which are accepting data. And when doing this time, we all the time create a snapshot and send them over to another appliance.
13:47
So, if there is any user who wants to access some data from one of the nodes, he can just access from one node. It's very convenient to do, thanks to ZFS.
14:00
So, this is how we design a file system. So, we have a local dump, which is basically our dump for our node, which we currently are. And we have another dump, which is basically a serial number of this other node. And all the time we receive and send this snapshot.
14:22
So, here is our snapshot list. This is a snapshot we received from one of our nodes. And this is the situation where we are actually sending the snapshot to the other machine. So, we keep one snapshot only to send the incremental snapshot from our machine.
14:44
When we add up this send, we basically remove that snapshot. Every snapshot is basically the date of when it was created. What is very interesting in ZFS is that it's still developing.
15:01
It's not like constant technology. So, when we are doing a multi-master cluster, we did have a little bit of overhead because ZFS, before sending the data, he needed to decompress the file system. So, when he was decompressing the file system,
15:23
he would send the uncompressed data over the network. So, in our case, it was like 16 times more than the actual data. So, when ZFS was sending the conversion, we typed it again to LZ4. Then we manually, on the other side, decrypt the data.
15:43
And then ZFS again compressed the data. There wasn't any other choice. But now, after some work, a new version of ZFS, we can basically send and receive data, and it will send and receive the compressed data.
16:01
So, what are the downsides of using ZFS? So, if we are creating snapshots, like for upgrades or a situation when our engineer needs to do some work, during this time and rollback, we will lose some data. So, for example, if our demos are storing some data in our appliance
16:23
and we decided to rollback, we basically lose the data that those demos store. Another thing is that we are using snapshots, so it cannot really rollback ZFS change. So, if we create a data set, or we change some compression ratio,
16:43
or we upgrade whole pool, we cannot rollback that because snapshot is only a data set property, so it doesn't care about any other data sets. And if there is some problem with the cluster,
17:01
so for example, if here we couldn't send the snapshot for some reason, and we try and try and try again still failing, we need this snapshot set all the time to do incremental snapshots. So, even if we remove data, our storage doesn't free the space
17:23
because it has a snapshot which basically keeps the space. So, what are the solutions for that? So, like I said, ZFS is still evolving, so in case of these ZFS changes, we have now checkpoints, which are basically a checkpoint of the whole pool.
17:41
So, we can create a checkpoint and play with ZFS, upgrade ZFS, add additional data sets, and so on. When we will revit to a previous checkpoint, everything will be rollback as well. Additionally, we have also bookmarks. So, you can convert a snapshot to a bookmark,
18:00
which in that case, all the data will be free from the snapshot, but only the information which block was freed will be kept. So, we don't need to keep the data any longer. This is good if we decide to optimize our root master solution. So, unfortunately, ZFS still has some downsides.
18:23
So, for example, if we have a situation where we have a big delete, for example, we delete some data set and a lot of space was freed, and our machine, for some reason, rebooted. We have problems that there was not enough RAM to import the pool.
18:44
Somebody says that we should have one gigabyte RAM for one terabyte of storage. Yes, this probably is true. So, we need a lot of memory for importing pools. Like I mentioned before, there is no full disk encryption in ZFS.
19:06
So, maybe in your scenario, the ZFS encryption is good enough. In our scenario, we wanted the whole disk to be encrypted. If something will go very bad, and with ZFS it's quite a complex system, so it may happen,
19:25
we would like to still be able to do something on our machine. And the same if we would like to decide to reset our machine factory settings. Because of that, we decided to use UFS. So, our data, our customer data, is configured that
19:46
first we have a gel design layer and then we have a ZFS file system on top of it. So, in our case, UFS contains only read-only operating system. There is no writing on those file systems.
20:02
We only keep the file system there. It's not encrypted. And if something goes wrong, we can still boot from this partition. So, if we, for example, want to only turn on the SSH, we can. We don't need to go to our appliance with some additional handwriting and so on.
20:24
Because this is only a read-only partition, so we still can boot from it. There shouldn't be any harm to that. So, this is how we configure our disks. So, first partition is not portable. Then we have a free partition for systems.
20:40
Every time when we upgrade our machine, a new partition is used. We have a swap zero, which is encrypted using a jelly with a one-time password. And then we have our data, which is encrypted with jelly. And then, on top of the jelly, we have our ZFS.
21:04
So, like I mentioned, we also are using a write-zip tool, which is used for parity. So, we also try to reflect that in the case of UFS. So, how we are doing it?
21:21
In case of system partition, it's quite simple. We basically put all the system partitions in one mirror. So, if any of two disks will fail, we still can operate. Because this is one big mirror, so nobody cares from which partition we will boot. It's a little bit more tricky with swap.
21:43
Because if we will put it in a whole big mirror, then we will lose a lot of data. So, for example, if we have a four gigabytes swap partition, then if we will put it in a swap, then we will end up with only four gigabytes swap partition.
22:02
So, to reflect write-zip promise, which means that we can remove two disks and we will still be able to work, we decided to group the swap partition into the group of three. So, in that scenario, you can remove two disks, wrap them to disk, and our system still won't work.
22:26
But we also get some more space for this swap. So, how does this process work? We are using something that is called attributes in GPP partition entry, right?
22:43
So, you can set some additional attributes per instance in the GPP table. So, like we saw earlier, if we are booting from system zero, we are setting a bootme flag for partition zero.
23:01
When we are trying to upgrade, when we override the system one partitions, and we set up two flags, bootOnce and bootMe. Which means that we will boot once from this particular partition. We reboot our machine and longer automatically removes bootMe.
23:21
So, from this moment, everything, if our machine would fail, we basically would go back to system zero. So, let's go with this failure scenario. We create a ZFS snapshot and just after the flag was removed, the upgrade error occurred.
23:43
I don't know. For example, we cannot upgrade our database or something else broken. The machine is rebooted again. In this scenario, we see that there is a bootOnce flag. So, all these flags we tried from this partition because there is no bootMe flag. So, we tried booting from the partition bootMe and from the partition system zero.
24:07
We are doing a rollback at this point and we also set a bootFailed flag in the partition that we failed to boot. And that's all. We can try an upgrade again. In case when we succeeded, our upgrade was, everything was working.
24:23
The bootOnce flag changes bootMe and the previous bootMe flag is removed. And when we are doing another upgrade, another system two is used and the same scenario is going.
24:40
So, because we have so many layers, for example, we have a swap that we have a mirror, we have a system which is mirrored, we have a jelly on top of the ZFS on top of the jelly. We cannot use any standard method to initialize new this. So, if you want to put new this, for example, one is broken, we cannot do that.
25:04
So, we need to configure the LED to do that for us. And unfortunately, we need to write our own script to do that. The ZFS daemon cannot create a jelly-encrypted data for us. So, what about the external storage?
25:20
We have a few options here. First is NFS. So, we are designing a security solution and the NFS doesn't support encryption or authorization. I don't think that NFS version 4 supports that, but I don't think there is still a big usage for that.
25:44
What is cool about that is that it allows you to mount on multiple machines. So, in case of our multi-master machine, it would be useful, but unfortunately we cannot use it because of those two reasons. So, our choice would be iSCSI.
26:03
It's a good choice to go with. It supports encryption, it supports authorization. In our case, the corporation we were working with didn't want iSCSI just because they didn't have a controller for that.
26:22
We are not able to mount on multiple machines, but we can live without it. So, last option is SAN over FC. There isn't encryption and there isn't authorization, but it's theoretically a separate network because it's only a storage network.
26:47
We can play with that and we can also configure jelly on top of the looms that are provided for us. So, in case when we get the jelly on top of those block devices that FC is providing us, we get encryption and authorization.
27:07
And also, all the network traffic which we send is encrypted because they are basically sending the jelly block. So, this is the solution that we go with. We also decided to use at least two FC channels.
27:25
We want to have some redundancy in our appliance. This creates a small problem as well because when we have a two FC channels and we are connected to the same storage machine, we see the same this, but with the different block, I mean different devices.
27:45
So, we can combine them using the gemulti path and solve this problem. This gem provider is very useful for that. So, what about the remote practices? Originally, we started with SSH.
28:01
Basically, we allow our customer to enable SSH in our appliance. Then, we can log into the machine. The problem is that the most secure way would be to use SSH keys because it's very hard to hide from them. But how to manage so many SSH keys?
28:24
Do we have SSH key per every client? This will create 100 keys for us. We can upload them somehow to machine, but still it's 100 keys. Again, what if one of our engineers changed the job?
28:42
We should invalid this key and send to the customer new keys. How long should we do that? It's also hard to force our customers to upgrade their machines. Our security appliance is kind of in the middle of everything. Some customers are not so happy to upgrade often because they need to have some time to do that.
29:08
Originally, we had just one master key which was shared by the employees and was rotated sometimes. Another problem with that is that this is an SSH key.
29:23
You cannot log in through IPMI or WebEx if our customer needs them. Some customers don't allow us to access their network. They say, okay, you can do some maintenance, but only through WebEx. How will you transfer the SSH key? Will you just give the SSH key to the customer?
29:43
We don't want to do that. Maybe password after all. Maybe, but it's very easy to hide everything which we type over the keyboard. We can just keylog it and the customer or anybody else can have the password. Again, what if our engineer changed the job?
30:02
Will we rotate the password in all our customers? This was kind of challenging for us, but we came up with some solution. Basically, we are using SC with some changes for us. Basically, what SC is, is that we are taking some secrets.
30:22
It can be some random value number, whatever, some random data. We need to store it somewhere in a secure way. Then, we are using some hash function and we calculate this hash function as many times as we want to use this key. For example, if we want to use this key for 50 times, we use hash function on this key 50 times.
30:50
The result of this hash, we store on our machine. When our engineer wants to log into this machine, he needs to give N-1 password.
31:02
Instead of giving N-1, the machine is calculating this hash one more time and is comparing if the stored value is the same as the calculated value. If it is, the password is correct. Then, the password given by the user is new secret.
31:20
Again, he needs to give another secret which will give exactly the same hash of the stored value and so on and so on. We considered it like 50 keys per day. The key length is 16-charts, so it's a little bit challenging to write sometimes, but it's okay.
31:42
Keys were taped every day. It also means that every day we calculate if we have a stored password in our appliance. For example, we store our appliance today and we want to log in tomorrow.
32:05
Tomorrow, we need to give a 51 password. Not the next password, but the 51. We need to rotate this password over and over. We also unify this password. This is something done by, for example, Google Authenticator.
32:22
You don't need to think if L and I is the same letter or not. It's pretty handy. This solves our problem when engineers leave our job. We allow him to fetch passwords only for this week.
32:40
If he would fetch this week and he would resign next week, he doesn't know any secrets on our appliance. The last topic which I would like to discuss is process security.
33:00
How we manage to keep our process secure. We cannot build everything from scratch. In our case, when we are using a lot of different libraries, very different protocols, we cannot build everything from scratch. We need to trust somebody that this library is working good.
33:25
Even if you build everything from scratch, it doesn't mean that it's more secure than the thing that is open-sourced. We also cannot audit everything. This is not our business. We want to build a security appliance. Even if you audit all the source code that we use, all the open-source code we use, it doesn't mean that we didn't miss something.
33:51
Who do you really trust? Do you trust your employees? Do you trust the open-source community? It's hard to say. Somebody from the security community came up with a very cool quote, which I really like,
34:07
which means that security stops where the trust begins. If you need to trust somebody, that means that there is no security in your application. Instead of trusting, we basically can privilege this source code.
34:25
What we are doing in our approach is that we put all the complicated logic in a privileged process, and we develop a very simple privileged process that communicates with a privileged process
34:41
and gives some access to the resources that it needs. Through a very simple ABC to reduce the trust that we need to check and we need to maintain. The communication between those two processes should be as simple as it can.
35:04
What can go for a privileged process? He can have access to a database. He can access storage. He can access network. He can maybe authenticate a privileged process, depending on the use case about the application we are building. It also can extend some capabilities on a privileged process.
35:26
What can a privileged process do? If a privileged process gives him, then he can have, for example, a single file descriptor to store some data. Maybe he needs one or two descriptors to access the network, which a privileged process will give him.
35:44
Like I said, it's implementing a complicated logic which we are not able to out. We can also limit, for example, RAM usage or CPU time that this process can use. How do we accomplish that in FreeBSD and Bion?
36:00
Basically, we use Lee and me for our IPC, which is a very simple IPC library which is shipped through BNC. We use Capsicum for the unprivileged process to close it in the sample. Capsicum is a sandbox technique which allows us to limit the access of the process to global namespaces.
36:28
It's a very simple syscall which, when you call it, you don't have access to any global namespaces. Also, Capsicum introduces the capability rights, which you can limit the descriptor further.
36:45
For example, when we have our storage descriptor which stores some data on the disk, we can say, OK, you can only write to this descriptor, but you cannot seek over this descriptor. You cannot overwrite our data that we already stored. For example, if there will be some package read from the network which would exploit our application,
37:06
we will hopefully store it and it cannot be overwrited by our attacker. Lee and me, like I said, it's a very simple library for IPC. It stores a very simple primitives like strings, number, bold.
37:26
It can store and release itself. But what is most important, which most of IPC doesn't implement, it also can send descriptors. So this is something that we will use often.
37:42
Is it hard? From our experience, it's challenging, but it's possible. Our company isn't very big, but we were able to sandbox use this technique to sandbox applications using OpenSSH, 3RTP, much more applications which are quite big.
38:05
So this approach is doable, and if you will design your application from scratch to do this privilege separation, it's very simple to build it. So how our demo can look like?
38:21
Let's say that we are writing some proxy demo that will accept some connection from network and will store all the data that came from the network. So we started with a privilege process which is waiting for some connection from the network.
38:41
There is some time it's connected to our process. We form and create a privilege process. So basically our privilege process, only what's known is that some connections are right. He doesn't know what protocol, he doesn't know what type of it, because he cannot speak in this language and he doesn't know protocol at all.
39:03
So the client is talking only with the unprivileged process. After that, let's say that the client is sending some credentials, let's say it's trying to authenticate, and only when the client authenticated so, we are leveraging the RAM and CPU limitation.
39:24
Now, instead of 10 megabytes, our application can have 100 megabytes. After that, the privilege process is creating a connection to the server, is passing it to the unprivileged process, and the same goes for the storage.
39:42
It creates some file, it's created a file descriptor onto this file, it's sent over that network and over that unique domain, so it gets to that unprivileged process. All those connections can be also limited. This connection doesn't make a really sensible limit,
40:02
because it's write and read to that server, but this software can be limited, to be able only to write to this file and not overwrite some data. Besides Capsicum, we also have a general and cloud API,
40:24
which also can be used to separate some programs. If our application for some reason cannot be Capsicum-ized, maybe we can close it in the jail. I also created some IPC to communicate, or we can use cloud API, which needs some more development than Capsicum,
40:43
but it's also possible to do it. Thank you very much, and maybe there are some questions about that presentation.
41:03
If you want to talk about the topic, or about something else related to that, I will be able to talk with you after the talk, and we'll be somewhere on that conference. Thank you very much.
41:24
There is actually a question. So, I'm a bit confused about the topic. Why did you want to use that as a task, or as a part? Because we don't use that as a task, so what were the other reasons? So, from our experience,
41:43
ZFS is kind of a big component of the operating system. If something were to crash in ZFS itself, we wouldn't be able to fix that with using ZFS itself, right?
42:02
Because if we need ZFS to put ourselves, and something is wrong with our ZFS, then we are not able to put anymore, right? So, it's mainly a fear of what we've done. Yeah, so our appliance was designed in the times where ZFS wasn't as stable as it is now.
42:23
So, yeah, mainly from this reason. And, you know, we don't need any additions from ZFS which goes for those system partitions. Because, of course, we could consider now using boot environment and so on, but our main reason is that what is our ZFS
42:41
will not work anymore. So, if you're going to build it now, is that still a concern? So, ZFS now is much more stable. That said, we still had some issue, for example, that we wasn't able to import the pool
43:03
when it crashed in some random moment. So, yeah, I think that this approach is the way to go. Especially if you are using ZFS in an algorithm.
43:21
Yeah, if you are overusing ZFS. Sure, I understood the 50 times hatching. Can you put that slide again? Yeah, sure.
43:43
So, basically, you are generating some secret. It can be whatever you want, right? And then you hash it 50 times. And this is the secret you are storing on your appliance, right? When this is the secret you want to which you are storing,
44:00
and this is the same secret. So, to auto-decay, the appliance knows this secret, right? So, to auto-decay, you give the previous secret, the previous hash from this secret, right? Because it's hard to calculate from this, the previous one. So, which appliance needs to do,
44:21
it only needs to hash once and decide, oh, is this hash the same that I know, this hash which I know? If it is, then you are auto-decayed, and the new secret is the hash which you provide. And to auto-decay again, the secret is the hash you provide. So, you need to know the secret that was calculated from this hash, right?
44:44
And it goes over and over and over. So, with the 50 hashes, is that we set up our daily limit for 50 hashes. So, let's say you want to have a hash for two days.
45:01
So, you are calculating that 100 times, right? So, the hash you are storing is this one, but you are storing it today, and you will log in tomorrow. So, instead of giving the next hash, which is meant to be for tomorrow,
45:23
you will give a 15 hash, which is for today, okay? And if we have more hashes, then 50 next hash will be the next day, and so on, and so on, and so on. Thanks to that, you are protecting yourself from brute forcing, and that somebody will get hashes, let's say,
45:42
or some of your employees will get 20 hashes and will not use any of them, and after, when he will be fired or change the job, he will start using it in the customer environment, okay? So, because we are skipping some of these hashes, we are protecting against that. I'm talking about SSTP for an issue.
46:09
Yeah, the key management. Yeah. If you look at the authorized principles feature, which is just like KI, then you would avoid a lot of the scenes over thought. Yeah, but you still would,
46:22
you would need to rotate it when, for example, because we would start a, how we would revolve the key, basically. This is the question. Because if you would revolve the key, we somehow need to inform all our clients, which often don't have access to the Internet,
46:42
that this key is revolved, right? I was just wondering if issuing, and I haven't looked at the details, but just issuing keys that don't last very long. Kind of the same ideas. Yeah, but this would be very problematic when, you know, when there is a problem in the client and one of our engineers doesn't have a valid certificate,
47:03
then the security officer should validate this, create a new certificate from him. That would be a little bit more tricky. With this, we also, because not only our engineers can now walk into the machine, we can also provide, for example,
47:21
such a key for our partners. Another problem with the KI is that you cannot pass it through Webex or an IBM app. So this also will not work. In this approach, you basically pass the password. So, IBM, Webex, whatever works. Even if the password will be hijacked,
47:41
nobody knows the next password. Okay, so thank you very much.