Backward and forward compatibility for security features
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 | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: 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/61632 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023281 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Library (computing)Scheduling (computing)Computer animation
00:37
Process (computing)SurfaceSoftware developerGroup actionSoftwareCodeInformation securityPhysical systemZugriffskontrolleCompilation albumAdditionDefault (computer science)State transition systemFingerprintSynchronizationConfiguration spaceLogicConstraint (mathematics)Computer virusWorkstation <Musikinstrument>Object (grammar)System callRevision controlData conversionLatent heatCartesian coordinate systemSemantics (computer science)Information securityPoint (geometry)Group actionExpected valueCodePattern languageRevision controlBeta functionControl systemGame controllerDependent and independent variablesRight angleMixed realityNamespaceVirtualizationConfiguration spaceLibrary (computing)2 (number)MultiplicationRootKernel (computing)Computer animation
06:18
StrutRule of inferenceComputer fileThread (computing)Rule of inferenceComputer fileCodeDifferent (Kate Ryan album)Object (grammar)System callSet (mathematics)Group actionCASE <Informatik>Functional (mathematics)Arrow of timeDirectory serviceException handlingOcean currentWritingComputer animation
08:35
Physical systemControl flowComplex (psychology)Kernel (computing)Link (knot theory)Arithmetic meanGame controllerComputer animation
09:19
Computer configurationTime evolutionRevision controlMathematicsDirectory serviceTopologyInheritance (object-oriented programming)WritingReading (process)Computer fileFile systemRevision controlCategory of beingKernel (computing)Group actionComplex (psychology)Configuration space2 (number)Computer fileBitCuboidInformation securityCartesian coordinate systemElectronic mailing listComputer animation
11:37
Kernel (computing)Process (computing)Software developerAttribute grammarRevision controlNumberSet (mathematics)Kernel (computing)Cartesian coordinate systemRevision controlEnthalpyComputer animation
12:40
Personal digital assistantSoftware developerGeneric programmingType theoryFocus (optics)Rule of inferenceRevision controlLatent heatRule of inferenceKernel (computing)CASE <Informatik>ImplementationSet (mathematics)Category of beingSoftware developerComputer animation
14:01
Local GroupRevision controlKernel (computing)Rule of inferenceReading (process)Directory serviceAnalogyRootRight angleException handlingGroup actionWeb browserComputer animation
14:58
Information securitySoftwarePersonal digital assistantError messageSoftware developerSoftware testingKernel (computing)User profileVariable (mathematics)Integrated development environmentConfiguration spaceLatent heatCodeComputer fileSystem call2 (number)Category of beingKernel (computing)CASE <Informatik>Information securityCodeIdentifiabilityCartesian coordinate systemExpected valueAxiom of choiceCodeRun time (program lifecycle phase)Computer animation
17:50
MathematicsError messageRule of inferenceNP-hardAxiom of choiceLevel (video gaming)Attribute grammarConstructor (object-oriented programming)Rule of inferenceComputer fileDirectory serviceBitCartesian coordinate systemMetreMultiplication signMathematicsPattern languageCASE <Informatik>CodeRight angleError messageState of matterComputer animation
19:53
InferenceUsabilityOpen sourceGoogolPatch (Unix)PredictabilityComputer animation
20:13
Link (knot theory)Computer animationProgram flowchart
Transcript: English(auto-generated)
00:06
Hi everyone, my name is Michel Salin, I work for Microsoft, and I'm mostly the, well, the mainer of LanLAC, which is a new schedule Linux feature, and yeah, it's about sound
00:24
basking. So this talk is about the ROS library we wrote for LanLAC, and well, we kind of had some changes, about compatibility. So yeah, just a quick introduction, context, to understand the programmatic here, so yeah,
00:45
why care about security, so here, well, it might be obvious for some, but like, every application can be compromised, every application can be trusted at first, and during the lifetime
01:01
of a process, it can, well, become malicious. So yeah, as developers, there's, well, multiple problems, so we don't want to participate to malicious actions performed by attackers through our software, and we kind of have a responsibility for users, and especially to protect their personal data.
01:25
And yeah, there's also the, well, there might be some issues about third-party code. So security sound basking is a security approach to isolate software, and mainly to isolate them by dropping ambient access rights.
01:41
So in a nutshell, well, when you launch an application in, like, a common Linux distro, this application can access a lot of files, including some which are kind of private, like .ecch, for example. So sound mixing should not be confused with namespaces and containers, which is a way to
02:01
create kind of a virtualized environment, and second is also something which is really interesting for security purposes, but it's not about access control. It's about protecting the kernel. That was initially the, well, initial goal of second. So Larnark is really dedicated from the ground to bring sound marking features to
02:25
Linux, so to bring some security features to the kernel. So it is an access control system available to every processes, you don't need to be a root or whatever, and it is designed to be embedded in applications, so to create
02:45
built-in sound basking. It's a way to create one or even multiple layers of new securities, so it comes kind of after all system-wide access controls which are already in place, and so it's available
03:04
on most distros nowadays, and if it is not the case, well, I encourage you to open an issue in your favorite distro. So about sandboxing here, what's the interesting point about sandboxing and built-in application security?
03:22
If we can create tailored security policies and embed them in the application. So there's interesting things about that, and that might help to make it security invisible, which is kind of the main purpose here.
03:43
We want to not bother users, but secure them anywhere. So because this security policy can be embedded in the application, well, it can use the application semantic. You can also use the application configuration, so you don't need to add another configuration
04:02
stuff. It's not another layer of execution, it's embedded in the application. And of course, well, if the configuration depends on user interaction, well, it can adapt to this change of behavior. And one really interesting point is, well, as a developer, you want to test what you
04:24
do, and you want to kind of get guarantees that whatever you're developing is still working. And being able to embed the security policies in your application, make it possible to test them the same way that you can test every other features, so that's really interesting.
04:42
You don't rely on, let's say, Linux being installed on your test machine and so on. And it adapts to the application over time, so if you have a CI which is well configured, you can test it and make sure that, well, you can add new features, update the security
05:01
policy, and make sure that everything works as expected. So speaking about the library and the Rust library, so the idea was to create something which is rusty, so idiomatic to Rust, and for this, well, we wanted to leverage strong typing to get some developing guarantees, and also to follow some common patterns,
05:25
so many here, the builder pattern. So it's still working for us, it's working, but yeah, we're working on improving the API and make it easier and more, yeah, easy to use for competitive revision.
05:41
So this talk about this kind of compatibility requirements, and yeah, so I talk about that. Some examples of early public users are listed here, but yeah, it's still in kind of beta for now. So let's start with some code examples.
06:01
So just as a warning, this kind of simplified code, it's working, but yeah, for the demo, well, it's not demo, but for this example, the idea is to make it simple to, well, to make it easier to understand. So you can see at the left, there's a C code, and at the right, the exact same semantic,
06:25
but in Rust, so I will mostly talk about the Rust code, but yeah, you can take a look at the C code to kind of see the difference between them and how Rust can be useful there. So as I said, it is based on the builder pattern, so you create a ruleset object here
06:43
with the ruleset new, and from there, you kind of call different methods to, well, build the object here, in this case, a ruleset, so a ruleset will contain a set of rules, and yeah, at first, you define what you want to enforce, what you want to restrict, what you want to deny by default, so in this case, it is two actions,
07:04
the action to execute files and the action to write on files, so obviously, it's not enough, but in this case, it's easy to understand for this simple use case. And then, once you define the ruleset and what the ruleset can handle, well, you can create it, and the ruleset creation translates to, you can see at the left,
07:25
there's a larnock create ruleset, and this function is in fact a syscall, so in the Rust part, when you call the create method, it creates a new ruleset, which is backed underneath by a new file descriptor, dedicated to larnock,
07:43
and that is wrapped in the ruleset object. Then, if you want to add rules to allow some directory to be, for example, executable, which is the case here, so you append the slash user directory, and you make it, well, executable, so arrow access, access first, execute,
08:05
and then you can add all the rules you want for all the exceptions that should be legitimate for the, well, legitimate use case, and then you restrict the current process, well, in fact, the current thread,
08:20
and from this point, the current thread can only execute files which are in slash user, and it cannot write anything at all, actually. So, that was an introduction, quick introduction to the library,
08:42
and the thing is, larnock is not a full feature access control yet, because, well, it is complex, and, well, to reach this goal, well, we need to spend much more years to increment, well, to add new features to the link scanner.
09:03
Yeah, and the thing is, well, sometimes, you might add new features that enable to restrict more, and sometimes, we might add some features to restrict less, so let's see what this means.
09:21
So, the first version of larnock, which was released with 5.13 kernel, basically allowed to read, write, and do a lot of common stuff, to restrict a lot of common file system actions, but there was, like you can see here, there's three categories.
09:40
So, first one, always denied, was for the first version of larnock, the action that was always denied whenever you sandboxed a thread. So, that was for, well, complexity in the development, but also security reasons. So, for example, you are not able
10:00
to execute set ready binaries, because it will be kind of a way to bypass the sandbox, and there was some restriction on ptrace, so you're not allowed to debug an application process, which is outside your sandbox. Obviously, it would be a way to get out a sandbox, so that's not what we want.
10:21
So, the second version of larnock had its new way, a new access right, which was a way to repound files. So, at first, it was denied to change the perpendicular of a file for security reasons, because larnock is based on five keys identification,
10:42
and that was kind of complex. So, but with the second version, we implemented that, and then it became configurable. So, one item left in the always deny box. In the third version of larnock,
11:00
so all these version are new kernel releases, and in the third version, we added a new way to restrict file truncation. So, truncation in general is to change the size of a file. And this was always allowed before, because it wasn't handled.
11:21
It was a bit complex to implement this in the kernel at the time, but now it is possible. So, you can see that we can move items from the always deny box to the configurable, and from the always allowed box to the configurable list. So, application compatibility.
11:41
There's two main things in compatibility. There's forward compatibility, in a way that when you update your kernel, you still can use the old kernel features. So, that's kind of common. And the backward compatibility, in this case, is, well, when you're using a kernel feature, well, you might need the specification of the kernel
12:00
that supports this feature. And if your application is running, is launched on an old kernel, well, that feature might be missing. And the thing is, when you're developing an application, well, you don't know on which kernel your application will run, because, well, it's a user choice, and a distro choice.
12:24
What comes with Landlok is the ability to get the Landlok, what we call the ADI version. So, it's really just a number that increments, I started at one, and then increments for each new set of features, which is added to the kernel.
12:41
So, to give you an idea, it's really simple to get this ID, this version. It's with Landlok-rate rules at Cisco, with a specific flag, so, yeah, it's a T-code, but it's really simple. So, what we want to do, at first, was these four main properties. The first one is to be able to, well, to make it easy to use for developers, of course.
13:05
So, we want something which is generic, which kind of follows the build-up pattern, because, well, it's kind of common and easy to use. We want developer to focus on what they want to restrict, not the internal, well, implementation in the kernel.
13:23
And we want them to gradually go from a coarse-grained access restriction to a fine-grained one. So, we don't want them to need to implement a fine-grained at first. It might be difficult, too difficult, so, yeah,
13:41
in the same way that we can incrementally add new set of features, we can also incrementally restrict more and more over time. So, no need to be super strict at first. And, yeah, it should be simpler to write, well, for the common cases.
14:03
Okay, at first, the first improvement was to create group access rights. So, let's say you know which analog version is supported by the running kernel. Let's say it's the second version. Then, you can create a new root set,
14:21
which will get all the access rights which are supported by this basic kernel. So, you just call the handle access with accessfs from all and then abi2. And then, you can do kind of same when you're adding a new rule. And this time, well, you want to add an exception
14:41
on the slash browser to make it readable. So, in this case, there's two main group, the from read and the from write. So, for example, the from read includes reading a file, but also reading a directory, so listing a directory. Okay, second property that we would like to have
15:03
is being able to enforce a strict restriction. So, even if we don't know on which kernel the restriction will run, on some cases, we might want to be sure that all features are enforced and restricted. There's two use cases here.
15:20
The first one is to test it. If you want to sandbox some applications, you want to make sure that, even if you're using all the sandboxing features, well, your application will work as expected. So, that's really important. And you don't want to run your application in an old kernel and kind of be fooled by the fact that your application is running
15:40
because there's no, well, not all security features are enabled. So, you want to cut these kind of issues in your CI. And also, for security software, you want to have some security guarantees. So, we want to have a way to follow the whole sandboxing with all security features that we embedded in our application.
16:02
The third property is to be able to enforce the best for security with some minimum requirements. So, that's kind of the opposite. And this use case is mainly for end users because end user, well, you don't know which kernel to reuse. And so, you want to be able to enforce
16:21
an opportunistic sandboxing. So, if they have a new kernel, well, they will be more protected. If they have an old kernel, they might not be protected at all, but that's not your choice, that's their choice. And at the end, they want to run your application anywhere.
16:41
So, another requirement is to be able to disable the whole sandboxing if some features which are required may not be met. And this approach should be easier to write than others because it is the most common thing to do. And the last property is being able to run,
17:00
well, to configure at runtime the sandboxing, but to make it in a way that you're running most of the codes. So, the idea is to be able to have kind of the same code running everywhere, almost, even if they don't have a recent kernel.
17:22
Why that? Because you want to kind of identify early kind of some issues which might be linked to the sandboxing code, and that if you have, let's say, two users using a recent kernel and four users using an old kernel,
17:41
well, you might want to test as much as possible with all your users, even if they don't have a newer kernel. So, the first approach we took was, so I'll go quickly here, there's three approach. The first one was to change, well, to add a new meter to the ruleset builder pattern.
18:03
So, it was simple method to set on set the best before approach. So, if it was false, it was required to have this feature. So, in the example, an eviction that need to move files from one directory to another, needed to have the accessfs refer access rights
18:21
to allow this access. And if it wasn't the case, well, the sandboxing should not be enforced. Otherwise, it will break the application. So, that is a requirement. And in this case, that was a way to kind of change the state of the builder over time.
18:40
So, this is kind of flexible, easy to understand, but there's some kind of cases. And yeah, it makes the code not really clean. Another approach was kind of to do the same, but this time with, instead of two shifts, enable or disable, there were three ways to change it.
19:01
The best effort way, the soft requirement, and the hard requirement. So, a way to make it best effort, a way to make it error out if there is any unsupported feature, and a way to disable the sandbox without error if some feature were not supported. So, that wasn't ideal, neither. And the last approach, which is currently working for us,
19:25
is kind of a new one. So, the idea is to make it still configurable and to follow all these properties, but to make it, well, a bit simpler and still flexible. So, here, in a nutshell, well, you can make a new rule set
19:41
that will error out if there's any unsupported features, but at the same time, you can specify which feature is required to enable the sandbox or not. So, that's kind of specific, but yeah, should be better. So, going forward, there's a lot going on in this first library, a lot to improve.
20:00
You have a new helper, you get a recommendation, and I encourage you to send back your prediction or others. And, well, there's some tips if you want to get some motivation here. There's some rewards program. So, thank you for attention. There's some interesting link here. This talk was kind of a dance, but I hope you enjoyed.
20:21
Thank you.