How to configure Security recommendations provided by AGL- documentation

Description

Where can we configure the recommendations provided by AGL in documentation.

Please guide with the process through which we can make recommended changes. 

Say for example :-

Domain

Config name

Value

Kernel-General-MAC-1

CONFIG_IP_NF_SECURITY

m

Kernel-General-MAC-2

CONFIG_IP6_NF_SECURITY

m

Kernel-General-MAC-3

CONFIG_EXT2_FS_SECURITY

y

Kernel-General-MAC-4

CONFIG_EXT3_FS_SECURITY

y

Kernel-General-MAC-5

CONFIG_EXT4_FS_SECURITY

y

Kernel-General-MAC-6

CONFIG_SECURITY

y

Kernel-General-MAC-7

CONFIG_SECURITY_SMACK

y

Kernel-General-MAC-8

CONFIG_TMPFS_XATTR

y

Let me know in which file we can make the necessary changes

Environment

None

Activity

Jan-Simon Moeller 
September 21, 2022 at 7:38 PM

After our discussion in the Application Framework call I would close this. Essentially it is the task of the implementer to choose the options for the use-case and the hardware used. So this too specific and we cannot do a single configuration at this point.

Ayush Kumar 
September 21, 2022 at 5:22 AM

Thanks for the resolution, , it cleared some points out. But can you give me some details from the point of security on kernel level & Platform level which AGL provide by default, keeping it as a base . Say for example I downloaded lamprey version of AGL and what is the default level of security I am getting by default, from the open-source side.

Scott Murray 
September 19, 2022 at 10:12 PM

A few of them are directly set in kernel configuration fragments that AGL applies to kernels built with the supported upstream build process for the reference platforms, look in meta-agl/meta-agl-core/recipes-kernel/linux/linux, the others are dependent on the defconfig provided by the BSP vendor kernel.  The thing to note is the document that you are looking at is considered very out of date at this point with the reality of how AGL is used (see my previous comment).  All downstream AGL members are expected to be doing their own security hardening and using their own custom kernel configurations.  There is definitely some potential for AGL upstream to more explicitly enable a base set of zero or low impact hardening options in the default kernel configurations that are used in testing and demos on the reference platforms, but there is no guarantee that doing so is useful to Tier1s or OEMs as they are not necessarily going to pick up any of our upstream kernel configuration.  Please let me know if this addresses your question.

Ayush Kumar 
September 19, 2022 at 3:17 AM

Can you please confirm me if AGL has directly recommended these safety configurations on kernel level from their end? Can the configurations be implemented on  AGL?

Scott Murray 
September 13, 2022 at 10:02 AM

Those are kernel configuration settings, so application is somewhat BSP dependent.  AGL does attempt to provide a consistent mechanism for applying kernel configuration fragments (.cfg files), but that is only enabled for the BSP layer kernels that are supported in the upstream tree (so e.g. the Renesas linux-renesas kernel for the rcar3 platforms).  Look at meta-agl/recipes-kernel/linux/linux-agl-config.inc to get an idea how AGL manages that for different BSP kernel recipes.

In general, AGL members have indicated that they consider security hardening something that they do in-house, so currently the upstream tree has not worked to ensure all of those settings are enabled on all platforms.  That is something that could potentially be revisited.  To add configuration in your own tree if required, you would need to add a kernel recipe bbappend in your own product layer to add a kernel configuration fragment or fragments to adjust the configuration. 

Not a Bug

Details

Assignee

Reporter

Components

Affects versions

Due date

Priority

Created September 8, 2022 at 4:59 PM
Updated November 14, 2022 at 11:16 PM
Resolved September 21, 2022 at 7:38 PM