José Bollo

After presenting key constraints of new cybersecurity standards UN R155/R156 regulations, the session presents how redpesk open source stack helps to address those concerns, especially with it secured-by-design architecture.

The UNECE WP.29 regulation R155 for Cyber Security Management and R156 for Software Updates have been adopted in 2021 by UNECE’s World Forum for Harmonization of Vehicle Regulations. This means that cybersecurity is now non-negotiable for accessing the market in more than 60 countries, starting in July 2022.

The open source secured-by-design stack redpesk helps to fulfill regulatory requirements by providing:

• MAC-enabled Linux distribution (SMACK/SELinux)
• secure microservices architecture
• integration with RTOS for safety
• Innovative container engine fitted for embedded
• LTS on full car life (approx. 20 years)
• SOTA support

I'm going to present a scheme R7RS compliant interpreter only named "TR7", a far successor of tinyscheme, meant to be included in other programs for scripting.

As I was searching a tiny scripting language for some project, I found tinyscheme. It is really venerable but old.

So I searched for a modern replacement in the existing one, browsing the very long list at http://community.schemewiki.org/?scheme-faq-standards#implementations.

And you what? I have not found one matching my criteria: r7rs compatible, only C, light, easy to add in C programs.

So I started to modify tiny-scheme to fit my requirement.

Before work, at noon rest, late in the evening, ... A long effort still not achieved.

I'd like to get a short time slot to present it.

What should be done of the PTags Linux Security Module?

PTags means Process-Tags, it allows to tag processes and is compatible with user namespaces.

What problem does it solves? How does it works? How can it be used and for what purposes?

Answers to these questions would allows to answer the main question: should it be part of linux tree?

PTags allows a system to attach tags to processes. The tags can receive values. The semantic of tags and of the values is not enforced and that is the big strength of that model that can be widely used for several purposes.

This talk will answer the following questions: - What problem does it solves? - How does it works? (including user namespace) - How can it be used and for what purposes?

It firstly came from studies on "user land" capabilities attached to APIs. But as the process of tagging can be more widely used in system, it became more generic and simply solve the problem of attaching data (or meta-data) to a process and its possibly forked children.

It works by writing or reading the file /proc/PID/attr/ptags. When reading the file, the tag list is read. When writing the file, the tag list can be changed under conditions. The file can be monitored using inotify to be alerted on write accesses that presumely change the content. An available C library implements common operations.

The implementation is aware of user namespace. It can thus be used safely in containers because a same process is able to expose different tags in different namespaces, depending on there history.

Examples will show that it can be used for: - managing capabilities in the user land - setting cookies on processes - publishing, or exposing, data or state of a process - passing data without IPC - managing lifecycle of processes - tracking forks - ...

In near future, objects will dialog together through internet or near field hadhock networks. What's about your privacy data? Recent use cases in the automotive industry have shown how much it can cost to under estimate hacker's skills. In our current work for designing a security architecture for cars and connected objects, we used smack LSM and cynara service for isolating applications and services from the baseline system. This model is base on the idea that application should not be trusted, it guarantees that no data can be stolen by application and it supports native, html5 and cloud models.

The market sells more and more connected objects. These objects have a computing unit and most of it are able to connect to some kind of cloud. This is a fact.

There are motivations and interests in developing open frameworks for creation of applications for such objects.

When developing the system and its application framework, master pieces of knowledges and feedbacks are expected from telephone industry, where iOS and Androïd showed the high potential of markets for applications. But a car is not a phone!

Do you lend or resell your mobilephone? Is your mobilephone potentially lethal?

For each of the previous questions the answer is yes when the word "telephone" is replaced by the word "automobile". But you could find other devices: camera, watch, television, refrigerator, ... However, automobile seems to be one of the most complex connected object. All of this brings in the front of the scene many usages that are reasking and enforcing our practicals of security and privacy.

This talk presents the security considerations linked to my work for AGL (Automotive Grade Linux). AGL is a project of the Linux foundation. AGL project released its first specification in spring 2015.

It will explain how isolation of applications and isolation of in-deep parts of the system are required to ensure privacy and safety.

The library eCoAP is intended to be this easiest way of writing simple CoAP service. Its design enforced expressivity, efficiency and memory usage. As such, this library is the library of choice for people designing small systems offering CoAP accesses.

• short presentation
• short examples
• advantages
• drawbacks

Adding a launcher to a binary allows to control some aspects of its execution environment of the target application. This is used to change the namespace (view of the filesystem) of the target application at launch time. An other mechanism is also setup: the process receives (or not) keys that can be checked by other applications for the purpose of controlling authorisations. When implementing this mechanism, lakes appeared on the extendibility of the /proc kernel's filesystem that we will expose here.

The mainstream user is now accustomed to install applications that declare needing privileges (GPS position, reading contacts, ...).

This kind of API privileges is hard to guaranty for native applications without a framework that linux does not provide by itself.

The described framework is made of 3 parts: - the installer - the launcher - the key manager

The installer is setting the launching mechanic. This is mecanic uses links, security extended attribute, and groups.

The launcher setups the namespace environment using namespaces and the authorised keys and launches the target application.

The key manager is a high efficient server that allows any service to ask if a process has a given key.

The mecanism of the authorisation keys allow privileges to be given once, never or to be asked by some popup daemon.

The key manager is made using a virtual filesystem implemented using FUSE for prototyping. But the study of this mechanism shown limitations of the /proc kernel filesystem and its link to the LSM. It does not allow to extend the subdirectories /proc/pid with security by process items. The question will be debated.

EIFFEL the language and SCOOP(*) allow the creation of a kernel without neither MMU nor processes but secured.

The removal of MMU and processes improves the switching time of contexts and minimize the memory cost of concurrency. The kernel provides unlimited concurrency and native synchronisation/acquiring of multiple resources.

The security is primarily given through EIFFEL's exports at the API level and is enforced by tightly coupling the kernel and the compiler. The low-level unsafe API are available only available to the kernel.

(*) SCOOP: Simple Concurrent Object-Oriented Programming

The common state of the art is focused on POSIX implementation: C programming, processes, threads, mutexes, etc... But this has some issues: one stack per thread with strong separation of processes made by the use of MMU.

By changing the language, this concepts are becoming obsoletes and the issues disappearing. But the security remains and even more is enforceable at an API level.

SCOOP, the Simple Concurrent Object-Oriented Programming, is expressing the concurrency inside the language (without need of IPC or IDL) by linking (sub)systems to abstract processors.

Each of the SCOOP abstract processor has its own isolated memory. The FLK (http://flhq.org) implementation ensures the isolation of the memory at the language level. This done, no MMU is no more needed. Yes, the memory is managed by the kernel, but using only one common addressing space, a flat model.

SCOOP provides the model of synchronizing multiple resources. This synchronisation is native and is made using Rhee's algorithm that can be distributed. Having this avoid any need of mutexes, semaphores.

Conversely, this model tends to multiply the count of abstract processor in a way that can not be implemented using threads because of their weight. But it allows to change the underlying mechanism. Abstract processors are not executed within a private context/stack but on the current execution context that crosses processors.

New security behaviours tends to include security at the API level. The coupling of the compiler with the kernel allow to enforce this behaviour at compile time, installation time and (if very paranoiac) at runtime.

Smack (Simplified Mandatory Access Control Kernel) is a linux security module particularily well suited for small systems.

After presenting basic concepts and tools related to Smack, some concrete models for implementing Smack will be exposed.

I usually share my handset or my tablet to people of my family. Is it really secure?

Will my child install a backdoor? Will my dear spouse send jokes by SMS in my name? Will my mother destroy sensitive data? And me? How can I trust the policy manager? Will installed applications respect the contract? Even if native?

For Tizen, the implementation of Smack is declined for several targets: * for telephonic handsets (mostly dedicated for one person); * for notebooks (where multi-user is really need -think to your children-); * for automobiles (where multi-user and multi-session/multi-seat is targeted).

Also on Tizen, installable applications (coming from a store) must expose their requirement and then conform to it. That is even more important for Tizen because it currently allows native and/or mixed applications to be deployed.

The policy manager can rely on Smack to achieve the security for the whole system.