ATREDIS PARTNERS
Google ChromeOS Security
Competitive Analysis Report

Project Team:Technical Testing: Jessie Chab, Tom Steele, Jordan Whitehead
Technical Editing: Shawn Moyer, Chris Bellows, Joshua Vaughn
Project Management: Joshua Vaughn

Table of Contents
Summary ....................................................................................................................................................... 3

Platform Selection ...................................................................................................................... 3
Key Conclusions ......................................................................................................................... 3
Claims Validation ........................................................................................................................................... 5

User Data Encrypted at Rest....................................................................................................... 6
Veri>ed Boot ............................................................................................................................. 13
No Privileged User .................................................................................................................... 20
Google Security Chip................................................................................................................ 24
Browser and Android Application Sandboxing ........................................................................... 28
Enterprise and Education Lockdown ......................................................................................... 38
Seamless Updates.................................................................................................................... 45
Remote Access ........................................................................................................................ 48
Appendix I: About Atredis Partners .............................................................................................................. 51

Atredis Partners

Page 2

Summary
Google engaged Atredis Partners to perform a competitive analysis to compare the security featuresof ChromeOS against other operating systems. To perform this analysis, Google supplied Atredis
Partners with a document outlining security claims made by Google regarding ChromeOS. Working
in conjunction with representatives of the ChromeOS team, Atredis Partners and Google selected
macOS and Windows 11 as the two operating systems to use for this comparison.
To perform this analysis, flagship hardware platforms for each operating system were chosen. Where
possible, Atredis Partners leveraged these devices and its operating system to show and con>rm
security controls and other features. For Windows 11 and macOS, this was used in conjunction with
documentation review from Apple and Microsoft. For ChromeOS, open-source code repositories
were used in addition to documentation.
Given the nature of this assessment, focus was placed on showing security features and controls of
the platforms and performing a best-effort validation and analysis. No attempts were made to bypass
or subvert these features. Past published vulnerabilities and exploitation details were used to gain anunderstanding of some security concepts, but they were not used to weigh the effectiveness of any
feature or control.

Platform Selection
A comprehensive analysis of every hardware and software con>guration would not be possible withina reasonable timeframe for this assessment. As a result, Atredis Partners selected hardware that, atthe time of testing, best highlighted the security and experience of each operating system. Eachdevice was updated, to ensure it was running the latest version of the operating system available atthe time of testing. The following platforms were selected:•

Windows 11 on Microsoft Surface Laptop 5•

macOS Sonoma on Apple M1 Macbook Pro•

ChromeOS on HP Elite Dragonfly Chromebook

Key Conclusions
Atredis Partners’ analysis of ChromeOS security features indicates alignment with the claims madeby Google. While there were some small areas for improvement noted, they do not show a major
discrepancy between the claims and the implementations of security features as tested, and instead
are opportunities to further improve the security of ChromeOS.

Atredis Partners

Page 3

ChromeOS is a purpose-built operating system that is designed for using cloud-hosted applications
and data, and where needed, Android applications. Windows 11 and macOS are workstation
operating systems, supporting a larger array of applications and workflows. Ultimately, the securityof each operating system must also be measured against that flexibility, because as always, additional
functionality also creates additional attack surface.
Out-of-the-box ChromeOS has a hardened default con>guration and behaviors, along with a designthat protects the user from unintentionally degrading system security. ChromeOS users do not needto understand the low-level security con>guration or hardening options available to their device’s
operating system in order to have the most secure experience available. With this in mind, whencontrasted with macOS and Windows 11, ChromeOS offers the most secure experience.
Nonetheless, macOS and Windows 11 can both be con>gured to a more secure state after installationand can match many of ChromeOS’ security controls. These operating systems also feature security
features that are not present in ChromeOS; however, these features exist in part out of necessity, as
the threat model for each operating system is vastly different.

Atredis Partners

Page 4

Claims Validation
Google provided Atredis Partners with a document with a list of security claims about ChromeOS.
Each one of these claims is a statement about the current state of ChromeOS security. Atredis
Partners evaluated each one with the goal of evaluating the validity of the claim. Where possible, acomparative analysis was performed against Windows 11 and macOS for similar or related
functionality to those claims made by the ChromeOS team. The goal of this analysis was to draw
empirical conclusions where possible and >nd areas where ChromeOS meets or exceeds its
competition, as well as areas where ChromeOS could improve.
The following top-level categories were formulated to encompass these claims.
•

User Data Encrypted at Rest•

Veri>ed Boot•No Privileged User•

Google Security Chip•

Browser and Android Application Sandboxing•

Enterprise and Education Lockdown•

Seamless Updates•

Remote Access

Atredis Partners

Page 5

User Data Encrypted at Rest
Encryption of user data limits the impact of a stolen or otherwise intercepted device by attempting toensure that data on storage devices is not recoverable. Encryption in operating systems can be
implemented through various methods, including encrypting the entire >lesystem or con>ning it todesignated directories. A good encryption strategy is dependent on key storage; using unsoundstorage strategies such as software-only components or unsecured hardware could allow an attacker
to recover these keys and as a result, the underlying >lesystem.
User does not even have the option for unencrypted user data on ChromeOS, and in the case of multiple
users sharing a device, each user's data is encrypted with different credentials such that one device user (orguest) cannot observe the data of another user even if they had some exploit to become the "root" user on
the device.
●

ChromeOS device owners can share the device with a guest user without fear that data from theowner's profile could be leaked to the guest user, and the guest user could also have the same
confidence that the owner would not have access to the guest data after logout.

●

On other operating systems one can often become an administrative or root user to read the dataof another user. On ChromeOS even if one user could become root through some exploit, the otheruser's data would still be encrypted by a key not known to that logged in user.
Google ChromeOS Claim

Validation
As this claim covers multiple attack scenarios and outcomes, it has been broken down into individual
subsections for a more granular analysis.

User Data is Encrypted by Default
User data within the realm of ChromeOS refers primarily to the information stored on disk and inmemory associated with the various actions the user performs on the device, such as browser history,
favorites, downloaded >les, application data, images taken with the device's camera, saved
passwords, auto->ll information, preferences, etc.
When a user is logged in, this information lives within the following locations on the underlying>lesystem, where {UID} is a salted cryptographic hash of the user ID.
●/home/chronos/u-{UID}●/home/user/{UID}●/home/.shadow/{UID}/mount/user●/home/chronos/user

Atredis Partners

Page 6●/home/root/{UID} for Android-speci>c user data.

●/home/.shadow/{UID}/mount/root/ for Android-speci>c user data.

The salt is generated during system initialization using secure random. It is stored on the >lesystem
at /home/.shadow/salt with a mask of 0644. The use of this salt can help protect against arbitrary>le writes as it makes >le paths unpredictable. To determine this salted hash for a given user, thecryptohome command can be used in Developer Mode. On the testing device there were two users

con>gured.
$ sudo cryptohome --action=obfuscate_user --user=atredistest23@gmail.com
94290c58ad465508ccf9e6271350cf4518000313$ sudo cryptohome --action=obfuscate_user --user=atredischild23@gmail.com
0c6063c62f66338869e9052a1e48693e987979a6

Data is mounted to the following locations when a user is actively logged in.
/dev/mapper/dmcrypt-94290c58-data on /home/chronos/user type ext4
(rw,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,discard,commit=600,stripe=16)/dev/mapper/dmcrypt-94290c58-data on /home/chronos/u94290c58ad465508ccf9e6271350cf4518000313 type ext4
(rw,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,discard,commit=600,stripe=16)/dev/mapper/dmcrypt-94290c58-data on/home/user/94290c58ad465508ccf9e6271350cf4518000313 type ext4
(rw,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,discard,commit=600,stripe=16)/dev/mapper/dmcrypt-94290c58-data on/home/root/94290c58ad465508ccf9e6271350cf4518000313 type ext4
(rw,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,discard,commit=600,stripe=16)

Each of these devices is encrypted using dm-crypt, which offers encryption of block devices andpartitions and is part of the Linux kernel. The output of dmsetup ls --target crypt shows thesedevices.
dmcrypt-94290c58-cachedmcrypt-94290c58-data
encstateful(254, 7)

(254, 22)
(254, 21)

Data and cache for each user account correspond to a pair of logical volumes:•/dev/C3PP1KC16N7BJU5N/cryptohome--94290c58--data•/dev/C3PP1KC16N7BJU5N/cryptohome--94290c58--cache

The output of dmsetup ls –tree shows the relationship between these devices.

Atredis Partners

Page 7

dmcrypt-94290c58-cache (254:22)`-C3PP1KC16N7BJU5N-cryptohome--94290c58--cache (254:11)`-C3PP1KC16N7BJU5N-thinpool-tpool (254:3)|-C3PP1KC16N7BJU5N-thinpool_tdata (254:2)| `- (259:1)`-C3PP1KC16N7BJU5N-thinpool_tmeta (254:1)`- (259:1)
dmcrypt-94290c58-data (254:21)`-C3PP1KC16N7BJU5N-cryptohome--94290c58--data (254:10)`-C3PP1KC16N7BJU5N-thinpool-tpool (254:3)|-C3PP1KC16N7BJU5N-thinpool_tdata (254:2)| `- (259:1)`-C3PP1KC16N7BJU5N-thinpool_tmeta (254:1)`- (259:1)

In addition to encryption of partitions using dm-crypt, the ext4 >lesystem uses fscrypt fortransparent encryption of >les and directories.

Encryption is Mandatory
The second component of the claim is that the user does not have the option to store their data
unencrypted on ChromeOS. By examining the preferences available to the user, including those moreadvanced features accessible within chrome://settings, particularly experimental con>guration
flags in chrome://flags, Atredis Partners found no user-accessible method of storing this data inplaintext on the device.

Encryption Keys are Unique per User
The next claim is that, in the case of multiple users sharing a device, each user's data is encryptedwith different credentials. By running dmsetup when logged in as each user, Atredis Partners
con>rmed that the encryption keys are unique.
The following is output when the user associated with the hash 94290c58 is logged in.
$ sudo dmsetup table --target crypt --showkeys
dmcrypt-94290c58-cache: 0 434282496 crypt aes-xts-plain64:64:logon:dmcrypt:c4fc51d920d6a8da 0 254:11 0 1 allow_discards
dmcrypt-94290c58-data: 0 434282496 crypt aes-xts-plain64:64:logon:dmcrypt:c4fc51d920d6a8da 0 254:10 0 1 allow_discards
encstateful: 0 131989504 crypt aes-cbc-essiv:sha256:32:logon:dmcrypt:656e63737461746566756c 0 254:6 0 1 allow_discards

The following is output when the user associated with the hash 0c6063c6 is logged in.

Atredis Partners

Page 8

$ sudo dmsetup table --target crypt --showkeys
dmcrypt-0c6063c6-cache: 0 434282496 crypt aes-xts-plain64:64:logon:dmcrypt:1ec768de8a1fa2fd 0 254:22 0 1 allow_discards
dmcrypt-0c6063c6-data: 0 434282496 crypt aes-xts-plain64:64:logon:dmcrypt:1ec768de8a1fa2fd 0 254:17 0 1 allow_discards
encstateful: 0 131989504 crypt aes-cbc-essiv:sha256:32:logon:dmcrypt:656e63737461746566756c 0 254:6 0 1 allow_discards

Note that the key data in the output is not the actual encryption key, which is stored securely in the
Google Secure Microcontroller in the device.

Encryption Protects Against Root
One security claim that elevates the security of ChromeOS for multi-user environments such as
Education and the Enterprise is the idea that a device user (or guest) cannot observe the data ofanother user, even if root access has been gained on the device. User data is encrypted using aseries of intermediate keys that use something provided by the user during login, be that a PIN,
password, >ngerprint, etc. As a result, obtaining root to the device alone does not allow one user todecrypt and view the >les of another user. Validation of this process was conducted using code andan architectural review of the cryptohome directory of the ChromeOS source code.
The token used to encrypt/decrypt a user’s data is loaded in TPM slot 1 when they're logged in; asseen below, the other users’ tokens are not loaded and therefore listed as Slot -1.
$ sudo /usr/sbin/cryptohome --action=pkcs11_get_user_token_info -user=atredistest23@gmail.com
Token properties for atredistest23@gmail.com:
Label = User TPM Token 94290c58ad465508
Pin = 111111
Slot = 1$ sudo /usr/sbin/cryptohome --action=pkcs11_get_user_token_info -user=atredischild23@gmail.com
Token properties for atredischild23@gmail.com:
Label = User TPM Token 0c6063c62f663388
Pin = 111111
Slot = -1

Though other users’ tokens are not loaded when those users are not logged in, with root access, theTPM and User Secret Stash (USS) of users across the device can be accessed.

Atredis Partners

Page 9chronos@vell-rev4 ~ $ sudo ls -l/home/.shadow/0c6063c62f66338869e9052a1e48693e987979a6/user_secret_stash/uss.0-rw-------. 1 root root 532 Oct 17 14:59/home/.shadow/0c6063c62f66338869e9052a1e48693e987979a6/user_secret_stash/uss.0
chronos@vell-rev4 ~ $ sudo ls -l/home/.shadow/94290c58ad465508ccf9e6271350cf4518000313/user_secret_stash/uss.0-rw-------. 1 root root 532 Jul 25 10:13/home/.shadow/94290c58ad465508ccf9e6271350cf4518000313/user_secret_stash/uss.0

As mentioned earlier, because these are tied to something the user knows and provides at login, thisdoes not allow for decryption. An exploit that can persist as root across logins could potentially gain
access to other users’ data post login, but this scenario is not in the spirit of this claim, and as shownin other sections is not likely to occur without a vulnerability in many portions of the system.

Users and Guests are Isolated
In a guest session, Atredis Partners looked through the plethora of system diagnostic information
that's available in the browser at chrome://about, particularly chrome://system, and did not identify
any remnants of other users' data, aside from output from certain logical volume diagnostic tools andlogs. While these logs showed the names of the user data logical volumes based on the user ID hash,there was nothing mapping those names to the user account names. If a user could read the salt
value from the >lesystem, in theory they could brute force the resulting hashing using a list ofusernames and domains.

Guest Data is Non-Persistent
To ensure that a guest’s data is not available to other users after logout, including subsequent guests,
the user data generated during a guest session must be entirely non-persistent and cleared upon
termination of the session.
To identify guest-related data, Atredis Partners saved a >le within a guest session and searched forreferences to the >le on disk in developer mode while the guest session was still active. The guest
data was found within the following binary >le.
/run/cryptohome/ephemeral_data/b3ce69079fa99b130a8ec9fc9961f180d2339d8a$ file b3ce69079fa99b130a8ec9fc9961f180d2339d8a: Linux rev 1.0 ext2 filesystemdata (mounted or unclean), UUID=080fa437-51ec-4f02-8321-95679dad2f92 (extents)(64bit) (large files)

With the newly identi>ed salted hash associated with guests, Atredis Partners searched for any otherevidence of the guest data on disk. While the user data directories existed within the same locations
as they did for other users, these directories were empty even when the guest session was active.

Atredis Partners

Page 10

Checking the output of mount for this ID as well, Atredis Partners found /dev/loop8 mounted innumerous places on disk with this ID, but most of these locations were empty.
•/run/daemonstore/session_manager/b3ce69079fa99b130a8ec9fc9961f180d2339d8a•/run/daemon-store/smbfs/b3ce69079fa99b130a8ec9fc9961f180d2339d8a

After exiting guest mode, this entire >lesystem blob was absent from disk; a search found no otherreferences to the name of the downloaded >le.

Comparative Analysis
macOS supports Full Disk Encryption (FDE) through its FileVault feature, while Windows 11 employs
a volume encryption approach primarily through its BitLocker feature. On the tested platforms, neither
was required by default.
BitLocker is supported on Windows 11 Pro, Enterprise, and Education editions. On devices with a
TPM, BitLocker is enabled by default when using a work, school, or personal Microsoft account.
BitLocker encrypts entire >le system volumes that may be shared by multiple users. Because of this,
it is possible for someone with administrative access to the system to view the >les of other users.
The volume is decrypted after the pre-boot process where the system and TPM ensure the system isin a known safe state. BitLocker can be disabled by administrator users. Enterprise and educational
environments can enforce the requirement to use it.
Windows 11, for all intents and purposes, has disabled the use of the traditional Guest account. It
can be enabled through the Microsoft Management Console but will not be able to login locally. It is
recommended that this user is not used. Windows 11 now offers a “Shared PC mode” where guest
users can login and use the desktop; there is also a kiosk mode where single applications can bepresented and used. This requires some advanced con>guration. There are settings to enable
deletion policies for these users. This is not a Windows Home feature.
Apple’s Secure Enclave that is available on modern Macs supports encryption of the >le system andis not something that can be disabled. It is inherent to the system design. It prevents decryption of
the internal SSD without booting from the same device.
FileVault, while not mandatory, is recommended for full device protection and can be enabled duringsystem setup. Using an Apple ID is optional for setting up the device. If a user chooses not to enable
FileVault or opts not to use an Apple ID, they can still proceed with the setup process, bypassingthese features.

Atredis Partners

Page 11Once FileVault is enabled, the disk will be encrypted until an allowed user supplies their password.
The users that can do this are managed using System Preferences. Once the device is booted, thedisk is decrypted, a user with administrator/root privileges can access any >les on the device,including those of other users.
macOS supports a guest user, although this is uncommon and must be explicitly enabled. Guest
accounts cannot access the >les of other users without the use of privilege escalation attacks. Files
created by guest users are deleted upon logout.

Conclusion
All of the platforms reviewed support encryption of data at rest at some level, and each support it tosome degree by default. With macOS and Windows there are some caveats. ChromeOS has the best
out-of-box support and the only design that can prevent users who have root access from directly
accessing the >les of another user.
Atredis Partners did not identify any areas of improvement or discrepancies between the stated claims
and the gathered evidence.

Atredis Partners

Page 12

Verified Boot
Verifying that a system has not been modi>ed by an attacker during system boot ensures that no
unauthorized code is present on the system. A common goal of an attacker is to establish somepersistent connection to a local or remote host. This can happen at many levels, including the BIOS
and bootloaders. Modi>cations, such as rootkits, bootkits, etc., allow attackers to maintain apersistent connection and, with enough privileges, are dif>cult to prevent.
Verified boot ensures that users feel secure when logging into a ChromeOS device by confirming that thesystem is unmodified at boot-up. Verified boot starts with a read-only portion of firmware which verifies that
subsequent code is properly signed to ensure that all executed code comes from the Chromium OS source
tree rather than from an attacker or corruption. An attacker cannot continue to "own" a machine throughpermanent, local changes. To that end, on boot, the firmware and other accessible regions of the systeminternals are verified to be in a known good state. If they aren't, then the firmware recovery process will be
initiated (or the user can request permission to proceed, which would make sense in the case of adevelopment install, for example). Each stage can verify the integrity of the next stage, all the way tomeasuring that the Chrome browser that we execute has not been tampered with.
Google ChromeOS Claim

ValidationVeri>ed boot begins with a read-only (RO) >rmware. The security of the entire veri>ed boot strategy
depends on the integrity of this >rmware. Firmware is stored in flash memory. Access to the >rmware
is controlled using a physical line that instructs flash to mark regions as read-only (RO). This is known
as a Write Protect (WP) signal.
The WP signal in legacy systems was controlled using a physical screw on the device. Because ofthis, it was possible for device owners (and commonly students) to open their devices and disable the
WP in a fairly trivial manner. Modern systems, including those tested by Atredis Partners, use aseparate chip that is controlled by the Cr50 >rmware. To disable hardware WP on modern systems,
users can use a debug board or a “SuzyQ” USB device to perform closed-case debugging (CCD).
The system must be in developer mode to make use of this debug cable and physical access isrequired.
During boot, the RO >rmware extends a TPM register with the current device mode. This register canbe read and validated by later components to have some assurance of the given mode forcompliance.
In addition to hardware, there is software WP. Software WP will not be effective unless the hardware
WP has been disabled. The status of WP can be viewed within developer mode.

Atredis Partners

Page 13crossystem | grep wpsw
wpsw_cur = 1# [RO/int] Firmware write protect hardware switch current position

This >rmware contains coreboot and depthcharge, which are open-source bootloaders. Each of theselinks against a veri>ed boot (vboot) library.
Coreboot selects a >rmware to load (selection is used for backup and recovery) and validates theintegrity of that >rmware using a root key. The root key is stored along with coreboot on the RO flash.
Depthcharge is responsible for selecting, validating, and booting a Linux kernel. The Linux kernel isvalidated using subkeys stored in the >rmware. During this process, rollback to outdated >rmware isalso detected and prevented.
Understating and validating this process was conducted by performing documentation andexploratory code review. While code review identi>ed that these processes were in place as with otherportions of this document, a full code review to ensure the security of their implementation was notconducted as it is outside the scope of this assessment.
The veri>ed boot process can be reviewed on ChromeOS by navigating to chrome://system andviewingtheveri>edbootsection.

This

isgeneratedbyrunningthecommand/usr/bin/dev_debug_vboot. There are a few interesting sections to this output that can further help

understand and validate the process of veri>ed boot.
Included in this output is the extraction of BIOS components from flash.
# Extracting BIOS components...
+ flashrom -p host -r /dev/null -iGBB:GBB -iFMAP:FMAP -iVBLOCK_A:VBLOCK_A iVBLOCK_B:VBLOCK_B -iFW_MAIN_A:FW_MAIN_A -iFW_MAIN_B:FW_MAIN_B
flashrom 1.4.0-devel on Linux 5.15.130-20472-g682e24dd583b (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x7688d000.
–snip–
Using regions: "FW_MAIN_B":"FW_MAIN_B", "FW_MAIN_A":"FW_MAIN_A","VBLOCK_B":"VBLOCK_B", "VBLOCK_A":"VBLOCK_A", "FMAP":"FMAP", "GBB":"GBB".
Reading flash... done.

Next, keys are extracted from the GoogleBinaryBlockHeader (GBB).

Atredis Partners

Page 14

# Pulling root and recovery keys from GBB...
+ futility gbb -g --rootkey rootkey.vbpubk --recoverykey recoverykey.vbpubk GBB- exported root_key to file: rootkey.vbpubk- exported recovery_key to file: recoverykey.vbpubk+ futility vbutil_key --unpack rootkey.vbpubk
Public Key file:rootkey.vbpubk
Algorithm:
8 RSA4096 SHA512
Key Version:
1
Key sha1sum:
0b187cf7f1c803ec1cc83a149e829340054e545f+ futility vbutil_key --unpack recoverykey.vbpubk
Public Key file:recoverykey.vbpubk
Algorithm:
8 RSA4096 SHA512
Key Version:
1
Key sha1sum:
e3c39daf95da1940936aa29eef2d101eb09905c0

Subsequently, they are used to validate the integrity of the >rmware.
# Verify firmware A with root key:
+ futility vbutil_firmware --verify VBLOCK_A --signpubkey rootkey.vbpubk --fv
FW_MAIN_A --kernelkey kern_subkey_A.vbpubk
Keyblock:
Size:
1720
Flags:
23 (ignored)
Data key algorithm: 7 RSA4096 SHA256
Data key version:
1
Data key sha1sum:
03e9e3e848d4b0fb16e2dd14389babe2667880e1
Preamble:
Size:
2164
Header version:
2.1
Firmware version:
1
Kernel key algorithm: 8 RSA4096 SHA512
Kernel key version:
1
Kernel key sha1sum:b047ada00a098f208eaba08a9d2fbf21fe6f023b
Firmware body size:
1946496
Preamble flags:0
Body verification succeeded.
# OK#
TPM=0x00010001, this=0x00010001# Verify firmware B with root key:
+ futility vbutil_firmware --verify VBLOCK_B --signpubkey rootkey.vbpubk --fv
FW_MAIN_B --kernelkey kern_subkey_B.vbpubk
Keyblock:
Size:
1720
Flags:
23 (ignored)
Data key algorithm: 7 RSA4096 SHA256
Data key version:
1
Data key sha1sum:
03e9e3e848d4b0fb16e2dd14389babe2667880e1
Preamble:
Size:
2164
Header version:
2.1
Firmware version:
1
Kernel key algorithm: 8 RSA4096 SHA512

Atredis Partners

Page 15

Kernel key version:
1
Kernel key sha1sum:b047ada00a098f208eaba08a9d2fbf21fe6f023b
Firmware body size:
1956864Preamble flags:0
Body verification succeeded.

Next, the Linux kernel is copied from disk and validated using the kernel subkey. This occurs for
multiple versions of the kernel, but one is shown.
# Examining kernels...
# copying /dev/nvme0n1p2 to kern_0...
+ dd if=/dev/nvme0n1p2 of=kern_0
65536+0 records in
65536+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 0.0508992 s, 659 MB/s
# Kernel /dev/nvme0n1p2:+ futility vbutil_keyblock --unpack kern_0
Keyblock file:kern_0SignatureignoredFlags:
23 !DEV DEV !REC !MINIOS
Data key algorithm:
4 RSA2048 SHA256
Data key version:
1
Data key sha1sum:
e20ba888da25ecf13f5f313598dee08b27552f91# OK#
Verify /dev/nvme0n1p2 with kern_subkey_A.vbpubk:+ futility vbutil_kernel --verify kern_0 --signpubkey kern_subkey_A.vbpubk
Keyblock:
Signature:
valid
Size:
0x4b8
Flags:
23 !DEV DEV !REC !MINIOS
Data key algorithm: 4 RSA2048 SHA256
Data key version:
1
Data key sha1sum:
e20ba888da25ecf13f5f313598dee08b27552f91
Preamble:Size:
0xfb48Header version:
2.2
Kernel version:2
Body load address:
0x100000
Body size:
0xc12000
Bootloader address: 0xd0e000
Bootloader size:
0
Vmlinuz header address: 0xd0e000
Vmlinuz header size:
0x4000Flags:
0Body verification succeeded.

The >nal step in the veri>ed boot process, to verify the integrity of the system partition, covers the laststatement of this claim. This portion of the >le system contains all the binaries used by the operating
system, including the browser (Google Chrome), system services, and system con>guration >les. The
integrity of this ensures that attackers cannot modify the system to establish persistence on a device.

Atredis Partners

Page 16

This is done using dm-verity. This is a Device Mapper target that is part of the Linux kernel. It allows
a system to verify the integrity of a block device to ensure that >les have not been modi>ed. This
provides a RO >le system that cannot be changed by an attacker. The Linux kernel con>g can beviewed by a user in developer mode and shows the use of dm-verity.
console= loglevel=7 init=/sbin/init cros_secure drm.trace=0x106 root=/dev/dm-0
rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1
dm="1 vroot none ro 1,0 6348800 verity payload=PARTUUID=%U/PARTNROFF=1
hashtree=PARTUUID=%U/PARTNROFF=1 hashstart=6348800 alg=sha256
root_hexdigest=66d3d411681059d060db99e218d4d40c001154f7e91b507c4a8b435e964670ff
salt=b517fcd5d9a2d10b832e6ab65c70252df90b310f8c1e928d02a04389ad0dbbcf" noinitrd
vt.global_cursor_default=0 kern_guid=%U add_efi_memmap boot=local noresume noswap
i915.modeset=1 ramoops.ecc=1 tpm_tis.force=0
intel_pmc_core.warn_on_s0ix_failures=1 i915.enable_guc=3 i915.enable_dc=4xdomain=0 swiotlb=65536 intel_iommu=on i915.enable_psr=1 usbstorage.quirks=13fe:6500:uComparative Analysis
Macs feature a Secure Enclave subsystem to root and enforce secure boot. The Apple SoC BootROM
starts the secure boot flow and is con>gured by a Secure Enclave signed policy, deemed LocalPolicy
by Apple documentation, that describes the security mode (Full, Reduced, and Partial) and contains
the signatures used to bootstrap secure boot. The LocalPolicy includes valid signatures for bothnormal and recovery boot modes. The LocalPolicy is paired to a selected installation, allowing multiple
versions of macOS to boot with different security policies.
By default, macOS will be con>gured to boot in Full security mode. In Full security mode, Apple
enforces a device-speci>c signature, linking each application installed to the physical device via the
Exclusive Chip Identi>cation (ECID). This process requires macOS to request a unique signature fromApple’s signing servers for each application installed. macOS also prevents application downgrade
attacks via a security version (deemed a security epoch in Apple’s documentation). Apple’s signingservers will not vend a signature for an application version prior to the latest, enforcing anti-rollback
protection.
In Reduced security mode, the application signatures are “global” indicating that they are not tied toan ECID and do not require/utilize the Apple signing server for each installation. The applications are
signed once and may be installed on any macOS device (running in Reduced mode) at any time.
Reduced mode also allows the installation and loading of third-party kernel extensions.
Finally, in Partial security mode, macOS will still enforce signatures along the boot chain but will allow
the boot of images signed via the device's Secure Enclave. This mode allows booting a non-Apple
operating system. In this mode, the Secure Enclave will prevent access to some decryption keys,

Atredis Partners

Page 17

attempting to prevent untrusted operating systems from attacking a trusted boot Apple operating
system.
macOS also features System Integrity Protection (SIP), which restricts the root user from modifying
sensitive portions of the system. This is aimed at preventing malicious software from modifying systembehavior. Disabling SIP requires the user boot into recovery mode. Additionally, macOS features thesigned system volume (SSV) that further protects the operating system from modi>cation.
Windows 11 supports UEFI secure boot, where each step of the boot process is responsible forverifying the next step. The intention of secure boot is to validate the UEFI drivers, the Windows
Loader, and other components before they are loaded. The Windows Loader then continues thepattern of veri>cation before loading as it loads additional Windows components.
“Secured-core PCs” can provide additional protections mitigating common attacks against secureboot. A Secured-core PC can leverage Intel’s Trusted Execution Technology (TXT) (or AMD
equivalents) for Secure Launch. Secure Launch lets Windows provide a root of trust back to the CPU
manufacturer, requiring less trust in the device >rmware while still ensuring a trusted version of
Windows is loaded. The hypervisor, secure kernel, and NT kernel are all validated during this start up
process. Secure Launch is not enabled by default on many Secured-core PCs, including the devices
tested by Atredis Partners.
Windows 11 uses a measured boot to provide attestation that can be reported to local antivirus or an
enterprise attestation authority. This can allow organizations to track a known good state for theirdevices and isolate potentially compromised devices. The measurements can also be utilized by thesystem in unison with a BitLocker-encrypted startup volume. Modi>cations to core components of theboot sequence will result in a failure to unseal the required encryption key.
When loading into Windows, a Virtual Secure Mode (VSM) can be used to isolate key operating
system components from the rest of the system. Secure boot variables are used to ensure this featureis enabled, preventing malware from simply disabling this feature.
The use of Hypervisor-Protected Code Integrity along with secure boot allows a system to ensure thatno untrusted modules can run in the kernel, ensuring a trusted platform. In an enterprise organization,
administrators can enforce further policies to lock in a required con>guration and specify policies thatfurther restrict what code can run on the secured system.

Conclusion
Each of the systems have mechanisms for ensuring the integrity of the boot loader and kernel. While
the mechanisms vary in their implementation, they each feature robust solutions based on a hardware
root of trust.

Atredis Partners

Page 18

macOS and Windows 11 each have mechanisms to protect system >les from being modi>ed and only
allow trusted or signed applications from running. ChromeOS exceeds these by ensuring the integrityof the system state. With the exception of a bypass, ChromeOS’s architecture prevents attackers fromestablishing persistent access to a device across reboots.
Atredis Partners did not identify any areas of improvement or discrepancies between the stated claims
and the gathered evidence.

Atredis Partners

Page 19

No Privileged User
Privileged access on an operating system could allow an attacker to make changes to the system,
gain access to sensitive information, establish persistence, and potentially perform lateral movement
throughout an environment. Consequently, escalating privileges and targeting users withadministrative access are common techniques.
There is no human "root" or "admin" user on ChromeOS without enabling "Developer Mode" that makes"verified boot" a little more lax, allowing your hardware to run custom (non-Google-signed) images andaccess to a "root" shell. ChromeOS makes it obvious when you're in developer mode by showing a special
screen at boot time that prompts you to take a specific action to begin recovery (and return to verified boot).
Google ChromeOS Claim

Validation
Users in ChromeOS are not associated with a Linux user ID and are not operating system users in
the traditional sense. As a result, they do not have a traditional privilege model. During device setup
the initial user is set as the device owner, which has some additional privileges in comparison tosubsequent users and guests; these include setting the time zone, controlling user access and guest
sign-in settings, and wireless network preferences.
This supports the claim that there are no root or admin-level human users. Services and processes
run as the root or chronos users, and the chronos user has sudo access. Access to these users is
not available via the desktop UI, and non-developer-mode systems cannot switch TTYs or otherwise
access a system terminal to log in as these users. Access is controlled in many places by reading
the cros_debug variable that is stored in NVRAM.
This value can be seen by opening the Chrome Browser to chrome://system/#bios_info andexpanding the information. All system con>guration options will be displayed with their current values,
including cros_debug.
Services use the crossystem command to get the status of this variable. For example, TTY availability
can be observed in the following >le, available in /etc/init/console-ttyS0.conf.

Atredis Partners

Page 20

# Copyright 2014 The ChromiumOS Authors# Use of this source code is governed by a BSD-style license that can be# found in the LICENSE file.
description
author"Terminal login service for VT""chromium-os-dev@chromium.org"# The console doesn't need any of the services provided by boot-services,# so it is safe to start it in parallel. We don't want the serial console# to wait for boot-services to start because if boot-services fails, we# want a serial console to debug the failure. We also don't want to use# failsafe because that requires boot-services to have started.
start on starting boot-services
stop on stopped boot-services
respawn
oom score neverenv TTY_BAUD_RATE=115200# This file is generated at build time by chromeos-base/tty.
scriptif crossystem "cros_debug?1"; thenexec agetty "${TTY_BAUD_RATE}" %PORT% linux
else
stop
exit 0fi
end script

PAM con>guration rules also check this value before allowing users in /etc/shadow (e.g., root andchronos) to login.
# If we're not in dev-mode, skip to the system password stack.
auth [success=ignore default=4] pam_exec.so \quiet seteuid \/usr/bin/crossystem cros_debug?1# Check if a custom devmode password file exists and prefer it.
auth [success=ignore default=1] pam_exec.so \quiet seteuid \/usr/bin/test -f /mnt/stateful_partition/etc/devmode.passwd# If we get to pwdfile, use it or bypass the password-less login.
auth [success=done default=2] pam_pwdfile.so \pwdfile /mnt/stateful_partition/etc/devmode.passwd# See if the account exists in /etc and does not yet have a system password# set. Only then will we allow password-less login access (see below).
# For accounts not listed in /etc, or that have a password, we do not want
# to allow them to log in.
auth [success=ignore default=1] pam_exec.so \quiet seteuid \Atredis Partners

Page 21

/usr/bin/awk -F: [ \BEGIN { ret = 1 } \$1 == ENVIRON["PAM_USER"\] && $2 == "*" { ret = 0 } \END { exit ret }] /etc/shadow# If we get here, allow password-less accessauth sufficient pam_exec.so \quiet seteuid \/usr/bin/crossystem cros_debug?1# Fallback to a system password if one was stamped in after initial build.

What this ultimately means is that many classes of attack are eliminated. For example, it is not possible
for an attacker to coerce a user into downloading and executing privileged code. The attack surface
is not eliminated entirely; an attacker armed with a ChromeOS or Chrome exploit chain could in theory
obtain privileged code execution. This greatly increases the cost and dif>culty of exploitation.
When booting a device into developer mode, it is obvious to the user that they are operating in thismode. The following picture clearly shows the message to the user.

However, once the boot process is complete there is no immediate or visual indication that the device
is operating in developer mode. Any indicator here cannot be trusted, as the device could alreadyhave been booted into a custom image.

Atredis Partners

Page 22Comparative Analysis
It is dif>cult to perform a comparative analysis here, as the paradigms are very different. Windows 11
and macOS both use a typical access control model historically used by operating systems. There
are various mechanisms in place for both platforms to control access to privileged behavior, but they
are not discussed as they are not relevant to ChromeOS’s paradigm.
On both platforms users can be given administrative privileges. For all intents and purposes there
must be at least one administrator account on the system. This account type is required to install
software, make con>guration changes, add accounts, etc. User accounts can be created that are
not administrators and can be provided >ne-grained control of the system.
There is no comparison to be made for developer mode for either the Windows 11 or macOS
platforms.

Conclusion
Windows 11 and macOS support a traditional model of users and user privilege levels. The conceptof a user within ChromeOS is very different in that ChromeOS users are not actually system users
and subsequently can only execute applications that are available within the UI. This can heighten
the security of ChromeOS users as by default dangerous permissions are not easily attainable withouta costly or dif>cult exploit chain.
Atredis Partners did not identify any areas of improvement or discrepancies between the stated claims
and the gathered evidence.

Atredis Partners

Page 23

Google Security Chip
Having a dedicated security chip means an attacker must have physical access to the device toattack sensitive information secured by the security chip, and even then, it is a dif>cult task. On
ChromeOS devices secured by the Google Security Chip, the sensitive data secured by the security
chip includes two-factor authentication credentials and user data encryption keys. The security chipis also instrumental in attesting the device mode, so that a device cannot claim it is in normal mode
while it is in developer mode.
Google security chip - available for authentication with both google and other websites for non-phishable
two-factor authentication that would require a power button press in addition to other credentials. The
Google Security chip protects access to user data and encryption keys. Even if an attacker had yourpassword and hard drive, they would not be able to decrypt your data on a different device. Brute force
attacks are also prevented by the Google Security Chip so that attackers can't try millions of combinationsof passwords or pin codes to attempt to log in to the device.
Google ChromeOS Claim

Validation
The Google Secure Microcontroller (H1) supports many security features throughout ChromeOS.
Included in these is the ability to act as a Universal 2nd Factor (U2F) key. This can be used to set up
authentication to third-party sites. Historically the power button was used to simulate physicalpresence, however, in newer systems a PIN or >ngerprint may be used. Atredis Partners validated theusability of this using the Chrome browser and several sites.

Atredis Partners

Page 24

In practice this works as designed; however, there are some sites that are not supported. This isbecause ChromeOS does not support client-side discoverable credentials. This is also known as
Device-bound Passkeys. This was validated using a debugger at https://webauthn.me/debugger. To
test this, the residentKey options were used.

When residentKey is set to “preferred” or “discouraged” registration is supported.
When residentKey is “required” the following message is shown in Chrome.

Atredis Partners

Page 25

As shown, attestation is supported.
The H1 also protects user data stored on the device. This was validated using a combination of device
review in developer mode and code review. Keys used for encrypting user data are stored on the
TPM, and as a result, they cannot be exported. This portion of the claim was validated previously in
the User Data Encrypted at Rest section.

Comparative Analysis
Windows 11 and later requires TPM 2.0, which is used by Windows Hello, boot attestation, drive
encryption, and the cryptography framework. The TPM is a key part of the device security for securedcore PCs.
Windows Hello supports passkeys which are tied to the TPM and are protected by a PIN or biometric
input. PINs or biometric access on the device are tied to the TPM so that the credentials cannot be
used over the network. The PIN code is stored in the TPM, which is dif>cult for an attacker to accessand requires physical device access. Windows Hello supports client-side discoverable credentials
and attestation.
Drive encryption can be tied directly to the TPM and device state, so that a BitLocker encryptedvolume will only be unlocked if the machine boots in a trusted state. The measurements recorded in
the TPM must match the previously trusted state for the drive to be able to unlock automatically,otherwise a recovery code must be used.

Atredis Partners

Page 26

macOS supports passkeys using Touch ID and FaceID when used on iOS. Private keys are generated
as part of the passkey creation process by the Secure Enclave. Key material generated by the Secure
Enclave is stored on the iCloud keychain and synchronized across devices. Touch ID supports clientside discoverable credentials and attestation. There are some limitations in attestation when using
Safari, as the Authenticator Attestation GUID (AAGUID) is set to all zeros. This can prevent a sitefrom validating the type of device that is used to generate and store passkeys. The iCloud keychain
is a robust solution and is effective in preventing unauthorized access to users’ passwords andpasskeys.
Filesystem volumes that are protected by FileVault use keys that are only accessible from the Secure
Enclave. Keys utilize a combination of the user’s password and a hardware UID. Because of the
Secure Enclave, all data is transparently encrypted using this hardware UID. As a result, it is notpossible to decrypt a >lesystem volume without having the disk attached to the same device.

Conclusion
Each platform has a hardware-based solution for ensuring that disks and >lesystems cannot be
decrypted on another device.
Windows 11 and macOS support a more seamless passkey experience. ChromeOS has limitations
that may prevent the use of passkeys on some sites. The use and support of passkeys is a volatileand evolving landscape, and it is Atredis Partners’ opinion that sites should support both solutions.
Opinions differ as well on the overall security of “resident keys” and keys synchronized across devices.
ChromeOS should attempt to evolve their solution (likely requiring a hardware evolution) to be morein line with the competitors, or state why they are not moving in this direction.
Atredis Partners did not identify any discrepancies between the stated claims and the gatheredevidence.

Atredis Partners

Page 27

Browser and Android Application Sandboxing
Modern users rely on their browsers to keep them safe and defend against untrusted sites. This
defense is in depth: warning users about known malicious sites, as well as mitigating the effects of avulnerable or malicious application. Strong sandboxing measures, especially around the browser, areimportant parts of the secure modern operating system.
ChromeOS protects against malicious webpages through safe browsing and site isolation, and malicious orcompromised Android apps that attempt to take over the user's device or steal user data -- web pages andAndroid apps only have access to the resources the user allows, and everything a user chooses to run issandboxed.
Google ChromeOS Claim

Validation
Comparing the security of modern browsers including Safari, Edge, and Chrome is a large andimportant aspect of security analysis. This analysis has been and continues to be covered extensively.
Because of this, and the fact that Chrome is a cross-platform browser, this document focuses on thevalidation and comparative analysis of the claims made by ChromeOS documentation, and identifying
areas where each browser may integrate with the platform and operating system.
ChromeOS employs several mechanisms to enforce process integrity and isolation, with the primary
security goal of preventing malicious websites and applications from gaining access to protected user
data or privileged operating system functionality.

Safe Browsing and Site Isolation
Safe Browsing is a security feature of the Chrome browser that provides protection against knowndangerous websites, downloads, and extensions. This feature comes in multiple protection levels andprovides some degree of customization. For example, the user can opt to have their credentials
checked against compromised passwords from public data breaches in a way that does not expose
this information to Google or any other third-party.
Atredis Partners found that the Safe Browsing feature was set to “Standard” by default, with the option
to enable “Enhanced Protection” or disable protection entirely (including a disclaimer that revoking
protection is not recommended). Google provides a decent level of transparency when presenting
the different levels of Safe Browsing protection available to the user. While “Enhanced protection” isa much more proactive and thorough approach, it requires browsing data to be sent to Google foranalysis. By providing the ability to opt into "Enhanced" protection rather than applying it by default,

Atredis Partners

Page 28

Google is maintaining a balance between data privacy and protection, allowing users to make an
informed choice about how they would like to be protected.
The chrome://safe-browsing page provides a plethora of real-time diagnostic and con>guration
information to inform users of what actions and decisions the Safe Browsing feature is performing.

In addition to warning users about unsafe sites, the Chrome browser can also take steps to mitigate
damage done by a malicious site. Site isolation is a security feature in the Chrome browser that loads
web pages into separate, isolated processes. On ChromeOS, the Site Isolation mode is set to "Site
Per Process" by default.

Atredis Partners

Page 29

With this setting, each site that a user visits will run in a dedicated rendering process. A malicious site
has less opportunity to affect or gather information from other sites. Even if a site can exploit thebrowser to achieve code execution, they must do further work to be able to pivot from the sandboxed
process and inspect the information of another site or access sensitive data. This raises the bar formeaningful attacks. For example, when loading https://www.atredis.com in a new tab, the following
process was spawned.
u:r:cros_browser:s0
chronos 29379 0.9 1.0 1186990012 171080 ?
S<l
13:53
0:01 /opt/google/chrome/chrome --type=renderer --enable-crashpad -crashpad-handler-pid=31708 --enable-crash-reporter=, --user-data-dir=/home/chronos--homedir=/home/chronos/u-fa08d0fb7c79cbbe0d04aa8daaa2d2ca6f10d999 --loginprofile=user --unsafely-treat-insecure-origin-as-secure=*.linux.test --origintrial-disabled-features=WebGPU --change-stack-guard-on-fork=enable --enablelogging --enable-webgl-image-chromium --log-level=1 --video-capture-use-gpumemory-buffer --lang=en-US --touch-selection-strategy=direction --num-rasterthreads=2 --enable-main-frame-before-activation --renderer-client-id=109 --timeticks-at-unix-epoch=-1701354152568391 --launch-time-ticks=16259866342 --sharedfiles=v8_snapshot_data:100 --field-trialhandle=0,i,13374301325095508805,10931272823515064104,262144 --enablefeatures=ArcAdbSideloading,Borealis,CameraEffectsSupportedByHardware,Crostini,CrostiniGpuSupport,EnableDspHotword,EnableNeuralPalmDetectionFilter,FeatureManagement1
6Desks,FeatureManagementBorealis,FeatureManagementDriveFsBulkPinning,FeatureManage
mentFeatureAwareDeviceDemoMode,FeatureManagementGameDashboardRecordGame,FeatureMan
agementOobeSimon,FeatureManagementOrca,FeatureManagementSystemLiveCaption,FeatureM
anagementTimeOfDayScreenSaver,FeatureManagementTimeOfDayWallpaper,FeatureManagemen
tUpdateNotification,FeatureManagementVideoConference,OnDeviceSpeechRecognition,Pep
per3DImageChromium,PluginVm,QuickUnlockFingerprint,SmartDim,UmaStorageDimensions

Looking speci>cally at the contents of /proc/29379/status, more information can be gleaned about
the various protections applied to this Chrome renderer process.
chronos@vell-rev4 /tmp $ cat /proc/29379/status
Name:
chromeUmask:0022. . .
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs:
1
Seccomp: 2
Seccomp_filters:
1. . .

When a process runs as a non-root user, as in Chrome’s case, granular root-level functionality can be
granted via Linux capabilities. The capabilities granted to this process are designated above by itemswith the Cap pre>x; this process has no inherited, permitted, effective, or ambient capabilities.

Atredis Partners

Page 30

Seccomp, speci>cally seccomp-bpf in the current iteration of ChromeOS, is a security feature within
the kernel that can restrict the syscalls that an application can make. The Seccomp value of 2 in thestatus output demonstrates that Seccomp is active for this process and a policy is applied. ChromeOS
uses seccomp-bpf to protect the kernel from any malicious code that may execute in userland.
Linux namespace information can be obtained for this process via the lsns command. In the following
output, the renderer process PID is denoted as being part of a single namespace, particularly a PID
namespace, with no other members (NPROCS notes the total number of processes within thenamespace with the NS ID listed in the >rst column). A single process running in its own PID
namespace is effectively isolated from all other processes on the system.
NS TYPE
4026534535 pid

NPROCS
PID USERCOMMAND
1 29379 chronos /opt/google/chrome/chrome

In addition to running pages in separate renderer processes, Chrome as a whole runs in a segmented
manner, where different components run in individual processes rather than a single overarchingprocess with all requisite permissions, access, and functionality. This provides a mechanism for thebrowser to follow the principle of least privilege where possible. To demonstrate this, Atredis Partners
observed all running processes for Chrome and identi>ed the following individual component
processes.
/opt/google/chrome/chrome/opt/google/chrome/chrome --type=zygote (3)/opt/google/chrome/chrome --type=gpu-process (1)/opt/google/chrome/chrome --type=utility (6)--utility-sub-type=network.mojom.NetworkService--utility-sub-type=storage.mojom.StorageService--utility-sub-type=ash.ime.mojom.ImeService--utility-sub-type=ash.ime.mojom.ImeService--utility-sub-type=ash.local_search_service.mojom.LocalSearchService--utility-sub-type=quick_answers.mojom.SpellCheckService/opt/google/chrome/chrome --type=broker (1)/opt/google/chrome/chrome --type=renderer (5)Numerous system services run under minijail with con>guration to run under their own distinct
Linux user UIDs and groups, so Discretionary Access Controls (DAC) can limit what resources theseapplications can process. Where necessary, root-like functionality is granted via Linux capabilities,
also applied via minijail. Minijail provides several command line flags that allow Linux
namespaces to be applied to these services. Namespaces allow processes to have their own isolated
view of system resources, where each namespace provides a separate instance of resources like the
network, >lesystem, process IDs, and more, essentially creating a sandboxed environment. This
namespacing provides another wall against an infected process accessing sensitive resources.

Atredis Partners

Page 31

To address some of the limitations of the other mechanisms and provide a robust and granular methodof Mandatory Access Control (MAC), SELinux is also leveraged in cases where stricter protections
are required. When deployed correctly, in addition to process isolation, SELinux helps enforce processintegrity by placing mandatory restrictions on what subjects (services and applications acting on
behalf of users) have permissions to interact with and modify a process's code, data, IPC
components, etc.
Atredis Partners found that although the ChromeOS system is in SELinux enforcing mode, where
SELinux is blocking all actions that are not explicitly allowed by the policy, there are numerous
processes running in SELinux domains that are con>gured as permissive, where any violations to thepolicy would be permitted and audited, rendering SELinux completely ineffectual for these domains,aside from auditing what actions would have been blocked if the domains were in the enforcing state.
For example, the currently deployed SELinux policy for the domain in which the Chrome browser runs
contains the following line.
permissive cros_browser;

This directive renders all policy rules de>ned in the >le as functionally unnecessary, where any
attempted violations to the applied policy are permitted and audited. Essentially, when considering
the Chrome browser, SELinux is not an active security mechanism.
That being said, the combination of Safe Browsing, Site Isolation, Linux namespaces, Seccomp
policies, and Discretionary Access Control provides suf>cient protection when considering the
primary security goal of ensuring malicious websites cannot compromise the integrity orcon>dentiality of user data and core ChromeOS components.

Android Applications and the ARCVM
To support the installation of user applications while maintaining the integrity of the system,
ChromeOS deploys ARCVM, an architecture that is integrated with the host in a way that allows forAndroid applications to run visually integrated with the desktop environment while functionally isolated
from the core ChromeOS system.

Atredis Partners

Page 32

Because ARCVM essentially runs an Android system, Android's built-in application and data-level
isolation features apply, such as each application running as its own user, with associated data >lesappropriately owned by the user/group; the Android subsystem also runs with SELinux in enforcing
mode, with no domains set to permissive.
The permissions model of Android also applies here, where applications have no access by default
and will request access to individual components as needed, such as the microphone, camera, andstorage, allowing the user to decide whether to grant access or keep it blocked. Atredis Partners
con>rmed that in this environment, granting the “Storage” permission speci>cally applies to the user’s
Downloads directory and no other areas of storage. Attempts to leverage symbolic links to reachother areas of the >lesystem from this directory were ultimately unsuccessful, as the user data
partitions are mounted with the nosymfollow option.
The ChromeOS version under test was using an emulated Android 11 environment; by enabling theLinux development environment and ADB debugging, this emulated environment could be accessed
like a typical unrooted Android device for further analysis. Atredis Partners leveraged this environment
to further explore the Android system for any potential attack surface or weaknesses that a malicious
or compromised application could exploit.
The Android data partition for each user's environment is mounted to /home/root/{UID}/androiddata/ on the root ChromeOS >le system, where {UID} is the salted cryptographic hash of the user

ID discussed previously in the User Data Encrypted at Rest section. That being said, this informationis only accessible to a user when Developer Mode is enabled. Like other user data on disk, it was
found to be encrypted using dm-crypt and only available for the currently logged-in user.

Atredis Partners

Page 33

/dev/mapper/dmcrypt-fa08d0fb-data on/home/root/fa08d0fb7c79cbbe0d04aa8daaa2d2ca6f10d999 type ext4
(rw,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,discard,commit=600,stripe=16)

Changes to the Android environment, such as installing new applications and updating app
preferences, were immediately reflected on this mounted partition on disk. Atredis Partners was
unable to leverage this mounted partition to otherwise access or influence unintended areas of thesystem via the emulated Android environment, once again largely due to the use of the nosymfollow
mount option.

Comparative Analysis
Across all the compared operating systems, sandboxing and isolation mechanisms are used toprovide protection. ChromeOS is more intimately integrated with the browser, so security paradigms
are slightly different. For example, in ChromeOS there is no separate application for con>guring thesettings of the OS and user accounts; this is all cloud-based and performed via the browser. Rather
than perform a full security comparison of the browsers available by default on Windows 11 andmacOS, which has been done previously and can be found publicly, Atredis Partners focused oncomparing the general application sandboxing mechanisms available on these platforms.
On macOS, in addition to standard UNIX-style Discretionary Access Controls based on user andgroup identi>ers, System Integrity Protection (SIP) is deployed. SIP is a form of Mandatory AccessControl (MAC) built into the kernel to prevent the modi>cation of critical system >les by malicious
applications or users. SIP also prevents the loading of unsigned kernel extensions and prevents
macOS system processes from being debugged and inspected with tools like dtrace. SIP can only
be disabled by restarting into recovery mode and running csrutil disable.
macOS also implements application sandboxing that is integrated with the XNU kernel via the
Sandbox.kext kernel extension. As explained with ChromeOS, sandboxing reduces an application’s

reach, hindering available malicious actions for a compromised process. Applications are required to
run within a sandbox to be accepted for distribution in the App Store. Applications are not sandboxedby default on macOS, they must be con>gured to use a sandbox via the com.apple.security.appsandbox entitlement. Sandboxed applications are limited to the actions speci>ed within theirrespective sandbox pro>les. There are some actions that a sandboxed application is not permitted toperform regardless of what's con>gured in the pro>le. These include privileged actions like loading
kernel extensions, con>guring network settings, etc. Each pro>le can either be in allowlist mode,
where all access is denied unless explicitly granted, or denylist mode, where all access is allowed
unless explicitly denied.

Atredis Partners

Page 34

macOS offers Gatekeeper that by default prevents applications that are not installed from the App
Store from executing. Privacy and accessibility settings prompt the users when new applications areattempting to read portions of the disk or perform various actions with privacy or security implications.
On Windows 11, along with Discretionary Access Controls based on user and group permissions,
Microsoft incorporates Mandatory Integrity Control (MIC), a feature designed to regulate access toobjects within the operating system. This method enforces access restrictions based on integrity
levels assigned to objects throughout the system, represented by integrity SIDs (secure identi>ers).
Browsers on Windows will often sandbox isolated processes with restricted tokens at an untrusted
integrity level. The integrity SIDs for securable objects are stored within the system access control list
(SACL). Any object without an integrity SID is treated as if it had medium integrity. The integrity SIDs
for security principals are stored in their access tokens.
Similar to Seccomp in the Linux kernel, Windows provides the ability to restrict what system calls a
process can invoke. This is done by setting the ProcessSystemCallDisablePolicy via the
SetProcessMitigationPolicy

function. ProcessSystemCallDisablePolicy leverages the

PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY structure, which de>nes several flags for

restricting syscall functionality. Browsers on Windows will also usually disable entire groups of system
calls by disabling win32k calls for isolated processes.
In addition to the sandboxing methods, Windows also supports a security mechanism useful for
preventing unwanted or unsafe applications from running. Smart App Control is a feature available
on Windows 11 that checks applications against a Microsoft security service to determine if it is safe
to run. If an application cannot be determined to be safe or unsafe, it will run if it has a valid digital
signature, otherwise it will be blocked. By default, this service is run in Evaluation mode. This mode
attempts to evaluate based on user behavior if it would be useful and chooses to set it to On or Off.
Users have manual control and can set this mode in the settings menu.
Advanced users can also specify AppLocker and Windows Defender Application Control policies tofurther specify what applications may run on a system, and what should be denied. These policies
can enforce code signing by trusted parties and effectively restrict execution on a Windows system.
AppLocker can apply restrictions to not only binary executables, but libraries and other executable
scripts as well. A system with proper restrictions can prevent the execution of many types ofvulnerable or malicious code, which can reduce the attack surface available to an attacker seeking afoothold on a system.

Atredis Partners

Page 35Windows also provides a reputation-based system for checking applications. Reputation-basedprotection is a number of security focused features that help defend against malicious software. Eachof the following are optional and are on by default.
●

Check apps and >les: Uses Microsoft Defender SmartScreen to evaluate the repudiation of
applications and >les that are downloaded using a browser.

●

SmartScreen for Microsoft Edge: Monitors sites and downloads a user navigates to andchecks them against known or suspicious malicious sources.

●

Phishing protection: Attempts to prevent users from disclosing their password into browsers
and applications and protect against password reuse.

●

Potentially unwanted app blocking: Unlikely other >le and application-based setting, thisdoesn’t check for malware but instead checks for software that may simply be unwanted,
such as adware.

●

Smart Screen for Microsoft Store apps: Uses SmartScreen on applications downloaded from
the Microsoft Store.

Isolated browsing uses Microsoft Defender Application Guard to execute Microsoft Edge in a
separated container using the system hypervisor. This hypervisor-based security strongly isolates thebrowser from the rest of the system, increasing the protections for the rest of the system should abrowser process become compromised. This feature is not installed by default and is managed using
the Windows Features control panel. It is not available on Windows 11 Home. Once enabled, users
can launch Microsoft Edge tabs and windows in an isolated environment. Settings are available forcontrolling how Edge will save data, handle copy and paste, print >les, camera and microphonesettings, and graphics settings. Some diagnostic details are available at edge://applicationguard-internals/. Among these is the command line used to launch Edge.
"C:\119.0.2151.97\edge\Application\msedge.exe" --user-datadir="c:\119.0.2151.97\edge\\User Data" --wdag-container --wdag-host-clientid=55c843f3-4706-448d-b648-dcac56501e0d --wdag-host-sample-id=34583603 --wdaghost-session-id=9 --wdag-host-ukm-client-id=0 --wdag-host-ukm-session-id=0 --wdagsqm-id=s:325E57CA-FA29-471F-AA7E-605CA976A265 --wdag-http-header-enabled --nofirst-run --no-default-browser-check --disable-prerender-ntp --disablefeatures=WebRtcHideLocalIpsWithMdns,msRobin,msDataProtection,msEndpointDlp,msIrm,msIrmv2,msMdatpWebSiteDlp --silent-launch --flag-switches-begin --flag-switches-end--wdag-navigation-id=00000000-0000-0000-0000-000002e57a27 --Windows can use a hypervisor (Hyper-V) for isolation of other important services. Core security
services such as the Local Security Authority (LSA) can use a hypervisor to isolate credential

Atredis Partners

Page 36information. Hypervisor-protected Code Integrity (HVCI) is another virtualization supported security
tool that seeks to ensure the Windows Kernel does not load any untrusted code.
A hypervisor tool usable directly by users is the Windows Sandbox. This is a Windows feature thatcan be enabled by Windows 11 Pro and Enterprise users which uses Hyper-V to run a virtualized
instance of Windows 11 as an isolated desktop environment. Users can run programs that are isolated
from the host operating system. The sandbox is not persistent and when it is closed all data is deleted.

Conclusion
Comparing Windows 11 and macOS to ChromeOS in this context identi>es key differences in theflexibility of each platform. For example, on Windows 11 and macOS it is possible to install and run
third-party applications, where this is only possible in ChromeOS by using an isolated VM. Becauseof this, Windows 11 and macOS have a number of security features aimed at preventing the executionof malicious or unauthorized software, whereas ChromeOS takes the wholesale approach of isolating
applications from the core operating system entirely.
The attack surface and protections implemented for browsers on each platform are similar and willcontinue to evolve. The default sandboxing of third-party applications using a VM reduces the
ChromeOS attack surface in comparison to Windows 11 and macOS.
Atredis Partners did not identify any areas of improvement or discrepancies between the stated claims
and the gathered evidence.

Atredis Partners

Page 37

Enterprise and Education Lockdown
In enterprise and educational settings, the nature of device use presents unique security challenges.
For enterprises, it's crucial to balance the need for employees to perform their tasks ef>ciently with
the imperative to protect the organization's information and systems. Security measures must enableproductivity while guarding against external and internal threats. In educational environments, thefocus shifts towards safeguarding user privacy and minimizing the risk posed by insiders, given thehigher likelihood of insider threats. This involves implementing controls to prevent students and staff
from adversely affecting each other, as well as the institution's applications and systems.
In an enterprise or educational environment, the system can be locked down in a way that allows noalternative means of browsing the Internet to work around restrictions put in place by an organization (byactions that might include disabling crostini and disabling guest users or addition of non-enterprise users).
Google ChromeOS Claim

Validation
When a ChromeOS device undergoes Enterprise Enrollment, it can be managed and monitored byEnterprise administrators via the Google Admin console. This console provides a plethora of highly
granular controls over the devices and accounts of enrolled users. While some degree ofmanagement and monitoring is available for Google accounts logged into other device types, suchas iPhones, Android devices, and device-agnostic Chrome browsers, ChromeOS was the primary
focus of this analysis and supports the highest degree of control.

Atredis Partners

Page 38

When speci>cally examining the claim that “the system can be locked down in a way that allows noalternate means of browsing the Internet,” Atredis Partners considered possible paths for accessing
web content, which over the years has become a feature integrated with a huge array of services andapplications. At the most basic level, as mentioned in the claim, if a user could log in as an unmanaged
user or enable unmanaged Guest mode on their organization-owned device, all account-level
restrictions would be circumvented; Guest mode is isolated from other accounts on the device and is
not managed. There is a managed Guest mode feature, which allows for limits on login time and someother restrictions, but that is not within the scope of discussion here.
By default, any Google user can log into an enterprise-enrolled ChromeOS device, even if they are
not a member of the organization; content/browsing restrictions will not apply to this user, but devicelevel restrictions, such as the ability to powerwash the device, will still apply. Administrators can limit
which users can log into the device by explicitly de>ning a list of users and/or domains, where
wildcards are accepted (e.g., *@example.com). Attempts to log in as other users are denied with thefollowing message.

Atredis Partners

Page 39

The granularity of control provided by the Admin Console extends to web content, including Chrome
Extensions, which can be blocked depending on criteria like installation source, extension type, andthe particular permissions requested. For example, an organization can disallow any extension thatrequests access to the device’s microphone.
Where security and content are concerned, the degree of customization available is immense.
Administrators have >ne-grained controls over things like which sites can run JavaScript, set Cookies,
load images, auto-play videos, auto-open downloaded >les, request access to Bluetooth devices, etc.
Atredis Partners found that when blocking domains, the documentation was helpful in explaining thevarious nuances, providing examples where needed. A subset of these examples can be found below.

Atredis Partners attempted a few well-known methods for bypassing domain restrictions. For
example, using an archive site, such as archive.org and archive.ph effectively bypassed therestriction. However, for some sites this does not provide a suf>ciently robust and interactive
experience.

Atredis Partners

Page 40

ChromeOS support for installing Android applications drastically increases the available paths toaccessing restricted content. Organization-de>ned URL restrictions do not apply to Android
applications running within the ARCVM. This is demonstrated below, where the atredis.com domain
is blocked on the host OS Chrome instance and allowed on the ARCVM Firefox application forAndroid.

Atredis Partners

Page 41This limitation is outlined in the documentation for the URL blocking setting, along with detailed
information on how to block URLs within Android apps. However, this con>guration is only available
for some apps; Atredis Partners found that these restrictions could not be applied to Web Browsers
such as Firefox and Opera. Given the vast number of browsers available in the Play Store, the best
approach would be to restrict Play Store access entirely, explicitly de>ning which applications shouldbe allowed on user systems, and adding the con>guration to block unintended URLs if there is any
opportunity for the application to access the restricted web content.

Advanced features that provide more indirect methods for accessing web content, such as the LinuxVM environment known as Crostini, can also be disabled. Atredis Partners found that when setting
up a test Enterprise environment, Crostini was disabled by default. As expected, after enabling thisfeature, the restricted web content could be accessed via the command line with built-in tools such

Atredis Partners

Page 42

as curl and wget. As noted in the Admin Console, blocking Linux VMs does not stop instances thatare already running on user systems; one unexpected behavior noted by Atredis Partners was thatonce Linux VM usage was blocked, a user with the Linux VM already enabled could no longer remove
the Linux development environment from their system. The feature had to be switched back to“Allowed” for the removal feature to have an effect.
To prevent users from subverting organization-wide security controls via Developer Mode, in addition
to removing the ability to enter Developer Mode when already enrolled in an organization, Enterprisecontrols will force a Developer Mode device to return to secure mode immediately once the device isenrolled.

Note that this only applies when the device is fully enrolled on initial startup, not when an Enterprisemanaged user logs into an unmanaged device. In the latter scenario, when a user logs into a
Developer Mode system with their enterprise account, they can still access the underlying >lesystemvia

Developer

Mode.

AtredisPartners

identi>ed

thecontent

policy>lein/home/root/{UID}/session_manager/policy/policy. This binary >le contained strings from thede>ned policy, including the list of blocked Play Store applications and URLs:{"applications":[{"packageName":"com.opera.browser","installType":"BLOCKED"},{"packageName":"org.mozilla.firefox","installType":"BLOCKED"}],"playStoreMode":"BLACKLIST","dpsInteractionsDisabled":true}
atredis.com
netflix.com
youtube.com

Atredis Partners edited this >le to remove one of the domains; it was still not accessible via Chrome.
After logging out, the enterprise user could no longer log in; the authentication process would simply
loop. This avenue for exploitation was not further explored, as Developer Mode comes with numerous
caveats about how system behavior can be affected.

Atredis Partners

Page 43

To reduce the likelihood of users tampering with these policies to undermine the organization's
security controls, administrators should have total control over the device during the provisioning andenrollment process, where the end-user only needs to log into the device with their managed Google
account.

Comparative Analysis
macOS allows enterprise and education users to use third-party Mobile Device Management (MDM)
solutions to control many aspects of the operating system and device. By using this, administrators
can restrict what software is installed and can be installed. Limiting browsing to Safari is not a goal ofthese systems or a goal of macOS. There are applications that can be used to load resources fromthe Internet. iPadOS is more a direct comparison for educational and enterprise environments that
require strict lockdown of users. MDM solutions can be used to effectively lockdown a device to only
use applications that are suitable for students and the needs of the enterprise.
Windows 11 SE is a version of Windows that is designed for education use. By default, it ships with alimited number Win32 and Universal Windows Platform (UWP) applications, including Microsoft Edge.
Administrators can use Microsoft Intune to make additional software available. This can effectively
limit the ways that students can browse the Internet; however, some applications other than Microsoft
Edge can load resources from the Web. For example, most Of>ce applications can load media
including photos and video.
In an enterprise environment, administrators can use >ne-grained policies and a combination of MDM
solutions to fully control a Windows 11 device.

Conclusion
Due to the number of applications available on macOS and Windows 11 (SE included) it is more likelythat students and enterprise users could >nd ways to bypass controls dedicated to restricting use of
the Internet to a single application. This is not a fair comparison to make given the language andcontext of the claim. A better comparison would be to compare the administrative expertise andassociated costs required to effectively control a fleet of devices across an enterprise or educational
environment. In this context, ChromeOS may provide the best solution given the limited con>guration
required to effectively lock down a device.
In reviewing the con>guration controls available to administrators for ChromeOS, Atredis Partners did
not identify any areas of improvement or discrepancies between the stated claims and the gatheredevidence.

Atredis Partners

Page 44

Seamless Updates
Operating systems, >rmware, applications, and other software will inevitably experience security
vulnerabilities. These vulnerabilities can be leveraged by attackers against users, exposing their
sensitive data or making use of their system without their consent. Without a comprehensive patching
and update solution system security can degrade over time, and the likelihood of exploitation
increases.
Users should not have to worry about “patching” their systems for security bugs. Updates (including security
updates) should be seamless.
This means that maintaining your security posture is simple: reboot and you’re up-to-date. ChromeOS isdesigned to boot quickly, which helps ensure staying up-to-date isn’t a burden for the user.
Google ChromeOS Claim

Validation
ChromeOS supports automatic updates by default. When ChromeOS has downloaded and installed
updates that need a reboot, a noti>cation will appear to the user in the bottom right corner stating“Update available.” The user then selects “Restart” to update, and after reboot all updates arecompleted. System updates will update all system components due to the highly integrated nature of
ChromeOS. Android applications or other VM isolated components may need separate updates.
Users can check for system updates manually using the Settings menu, which will also show if theuser is up to date.

Atredis Partners

Page 45

Android applications are updated from the Google Play Store and have their own update settings; bydefault, updates are performed and applied automatically.

Comparative Analysis
Windows 11 offers automatic updates for the operating system, device drivers, and Windows
Defender de>nition >les. Windows will attempt to install these updates as soon as they are
downloaded. If a reboot is required to apply updates, Windows will attempt to reboot the systemoutside of the user’s de>ned “Active hours” when the user is signed out. Users will also be shown anoti>cation when interacting with the power button in the Start menu. Options are available to apply
updates and reboot as soon as updates are available, as well as notify users when a reboot is required;

Atredis Partners

Page 46

these options are disabled by default. Windows update can also manage updates for Microsoft Of>ce;
this is also disabled by default.
macOS also supports automatic system updates, and they are enabled by default. There are various
additional settings to control updates including the following.
●

Download new updates when available (Enabled by default)○●

Install macOS updates (Disabled by default)○●

Allows the system to install updates automatically.

Install applications updates from the App Store (Disabled by default)○●

Allows macOS to download updates as they are available instead of at time of install.

Allows the system to download and update applications installed from the App store.

Install Security Responses and system >les (Enabled by default)○

Allows the system to apply security updates more rapidly as they are supplied fromApple. This is useful as they can be applied faster than the typical update process.
Updates are speci>ed by a letter following the macOS version (e.g. macOS 13.3.1 (a)).

In practice, some of these settings frequently do not behave as they stated, particularly the
downloading and installation of updates. Many updates for macOS require accepting new Terms ofService and entering the user’s administrator password.
Both macOS and Windows provide stores of applications and manage updates for installed software.
Applications that are not installed through the Microsoft Store on Windows 11 or the App Store on
macOS require their own update processes. Often these applications come with their own update
services, use a package manager, check for updates when launched or at a de>ned interval, or
require the users to check and apply them manually. These non-store applications are not managed
by the operating system and may lack suitable update mechanisms.

Conclusion
The ChromeOS update experience is more seamless, requiring less user intervention than Windows
11 and macOS. This is due to simple settings with secure defaults, requiring minimal interaction to
perform updates. Third-party applications on ChromeOS are managed by a store which also provides
updates.
Atredis Partners did not identify any discrepancies between the claims made by Google and theexperience validating this claim or using ChromeOS throughout the assessment.

Atredis Partners

Page 47

Remote Access
Exposed network services increase the remote attack surface of an operating system. Any weakness
in these services could provide a direct opportunity for an attacker to gain a foothold and potentiallymove laterally or escalate privileges. Along with the attack surface, it is vital to examine the security
controls available to limit network access and functionality, the ease-of-use of these controls, and theoperating system’s general design of network services to ensure the system provides a strong
framework for protecting the user from unwittingly exposing the network to potential attacks.
Attackers can’t access ChromeOS devices remotely by default, users have to explicitly allow Android
applications specific access (for example, a VPN).
Google ChromeOS Claim

Validation
ChromeOS uses iptables to con>gure the Linux kernel Netfilter subsystem as a >rewall. The rules
deploy a default deny policy for ingress, and only ICMP, Simple Service Discovery Protocol (SSDP),and multicast (mDNS) are allowed. SSDP and mDNS are protocols used for device discovery andwhen attempting to identify >leshares on a local network.
The user is not able to modify these rules directly, and there is no ability to limit egress connections.
This was validated using iptables from a developer console; additionally, traditional network scanning
tools con>rmed that there was no default remote access.
$ iptables -L -v -n
Chain INPUT (policy DROP 188 packets, 7160 bytes)
pkts bytes target
prot opt in out
source131K 352M ACCEPT
all -- **0.0.0.0/0
RELATED,ESTABLISHED
165 10822 ACCEPT
all -- lo *0.0.0.0/000 ACCEPT
icmp -- **0.0.0.0/0
1327 279K ACCEPT
udp -- **0.0.0.0/0
286 59638 ACCEPT
udp -- **0.0.0.0/0

destination
0.0.0.0/0

state

0.0.0.0/0
0.0.0.0/0
224.0.0.251
239.255.255.250

udp dpt:5353
udp dpt:1900

Service discovery protocols are often used by attackers to poison requests and coerce systems into
connecting to resources they control. During review of the attack surface and susceptibility of these
attacks, it was identi>ed that the NetBIOS Name Service (NBNS) may be used when attempting tomount a >leshare; however, poisoned (and all) responses are not allowed by the >rewall. mDNS issusceptible provided the user is using the .local TLD when using Chrome. Even then, poisoning isdependent on timing between an attacker and a legitimate device, and mDNS is not used when
adding new >leshares, reducing the likelihood of successful attacks against mDNS.
Two additional ChromeOS features theoretically have the potential to expose services. The >rst is
ChromeOS support for Android applications. These applications are installed and executed using theAtredis Partners

Page 48

Android Runtime on ChromeOS (ARC) paradigm. The latest version, ARCVM, uses a virtual machine(VM) on top of Kernel Virtual Machine (KVM). These applications may create listening network
services, but they are not available over the network.
Second is Linux developer mode, which creates a VM where users can run Linux applications andaccess a terminal. Network services inside of this VM can be exposed to the network using the Port
forwarding UI. This creates multiple iptables rules that modify the INPUT and FORWARDING chains.

Comparative Analysis
macOS provides a built-in >rewall that is disabled by default. The Application Firewall (ALF) differsfrom a traditional network >rewall that uses IP addresses, ports, and protocols in that it operates at
the application layer and uses process identi>ers to control access on a per application basis. The>rewall can block incoming connections but has no capability for limiting outgoing connections. Thirdparty solutions or pfctl (a tool used to control an additional >rewall) are required for this. Dependingon the pro>le deployed, applications may be allowed to accept incoming connections. There are noservices exposed by default that enable remote access; however, applications and system services
may expose themselves to the network, which increases the attack surface.
Windows 11 uses the Microsoft Defender Firewall to >lter incoming and outgoing network
connections. The >rewall is enabled by default and comes con>gured with multiple pro>les. Rules are
separated into Inbound and Outbound groups and can be con>gured by a user in numerous ways.
These included multiple UI options as well as command line utilities. It is not typical for a user todirectly interact with the >rewall and create rules. Instead, when an application attempts to listen for
an incoming connection for the >rst time, the >rewall will prompt the user and ask if they would like toallow it, and a new rule is created. More commonly, an application’s installer will modify the >rewall
rules directly. Depending on the pro>le used, services that can be used by attackers to facilitate
remote access may be exposed. The default policy does not allow for Network discovery or File andprinter sharing. Additionally, common protocols used to identify a live system such ICMP are also notenabled. Network discovery allows for the use of multiple broadcast protocols to identify a device on
a network. File and printer sharing exposes NetBIOS and Server Message Block (SMB) services tothe network. Historically these present a large attack surface and, in a domain environment, arecommon targets.
Both macOS and Windows 11 are susceptible to poisoning via various protocols, including mDNS
and NBNS. In practice, Windows is the most targeted platform in this regard, this is due to theavailability of public tools and the impact of a successful attack. NBNS and Link-Local Multicast Name
Resolution (LLNR) are particularly susceptible. mDNS has the same constraints as attacks describedagainst ChromeOS.

Atredis Partners

Page 49

Conclusion
Due to default behavior, the abundance of con>guration options, and the ability for applications tomodify behavior, ChromeOS emerges as the most effective solution at limiting remote attack surface.
No discrepancies were identi>ed between the ChromeOS claim and testing performed. An area ofimprovement for the ChromeOS team would be to remove support for NBNS completely. However,this may be dif>cult as it is built into underlying components used by the platform.

Atredis Partners

Page 50

Appendix I: About Atredis Partners
Atredis Partners was created in 2013 by a team of security industry veterans who wanted to prioritize
offering quality and client needs over the pressure to grow rapidly at the expense of delivery and execution.
We wanted to build something better, for the long haul.
In six years, Atredis Partners has doubled in size annually, and has been named three times to the SaintLouis Business Journal’s “Fifty Fastest Growing Companies” and “Ten Fastest Growing Tech Companies”.
Consecutively for the past three years, Atredis Partners has been listed on the Inc. 5,000 list of fastest
growing private companies in the United States.
The Atredis team is made up of some of the greatest minds in Information Security research andpenetration testing, and we’ve built our business on a reputation for delivering deeper, more advanced
assessments than any other Trm in our industry.
Atredis Partners team members have presented research over forty times at the BlackHat BrieTngs
conference in Europe, Japan, and the United States, as well as many other notable security conferences,including RSA, ShmooCon, DerbyCon, BSides, and PacSec/CanSec. Most of our team hold one or moreadvanced degrees in Computer Science or engineering, as well as many other industry certiTcations anddesignations. Atredis team members have authored several books, including The Android Hacker’s
Handbook, The iOS Hacker’s Handbook, Wicked Cool Shell Scripts, Gray Hat C#, and Black Hat Go.
While our client base is by deTnition conTdential and we often operate under strict nondisclosureagreements, Atredis Partners has delivered notable public security research on improving security at
Google, Microsoft, The Linux Foundation, Motorola, Samsung and HTC products, and were the Trst
security research Trm to be named in Qualcomm’s Product Security Hall of Fame. We’ve received four
research grants from the Defense Advanced Research Project Agency (DARPA), participated in research
for the CNCF (Cloud Native Computing Foundation) to advance the security of Kubernetes, worked withOSTIF (The Open Source Technology Improvement Fund) and The Linux Foundation on the Core
Infrastructure Initiative to improve the security and safety of the Linux Kernel, and have identiTed entirely
new classes of vulnerabilities in hardware, software, and the infrastructure of the World Wide Web.
In 2015, we expanded our services portfolio to include a wide range of advanced risk and security program
management consulting, expanding our services reach to extend from the technical trenches into theboardroom. The Atredis Risk and Advisory team has extensive experience building mature security
programs, performing risk and readiness assessments, and serving as trusted partners to our clients toensure the right people are making informed decisions about risk and risk management.

Atredis Partners

Page 51