What we all need (pretty desperately TBH, and for many things that
goes from authentication systems up to proper keyrings and password
managers) it's a proper secure enclave in the linux systems using
Virtualization-Based Security (VBS).
There are already some implementations for the Linux kernel on which
both MS and Amazon are working, and I feel that we should ensure that
the ecosystem is ready for that.
Cheers
Il giorno dom 8 mar 2026 alle ore 16:21 Personal (disroot.org) via
ubuntu-devel <ubuntu-devel@lists.ubuntu.com> ha scritto:
>
> 4 Mar 2026 05:12:31 FloofyWolf <debian-devel-list@floofywolf.net>:
>
> > Recently, a proposal has been made to implement an API for a new
> > California censorship regulation, "On the unfortunate need for an "age
> > verification" API for legal compliance reasons in some U.S. states" by
> > Aaron Rainbolt. I believe the approach outlined to be very
> > short-sighted, in that creating a bespoke API for each of the hundreds
> > of government censorship requirements that debian will presumably now
> > be following will result in much duplication of effort and an
> > unreliable user experience in which important censorship restrictions
> > may be missed and not implemented. As such, with people now supporting
> > the idea that debian should implement government censorship requests,
> > even creating new standards if needed, I propose the creation of a
> > censorship framework to speed implementation of current and future
> > censorship regulations.
> >
> > On installation, the user will be required to enter their location.
> > This information may be pre-filled if device location (GPS) or other
> > sources of location data (IP geolocation, selected timezone, etc) are
> > available. If the user enters a location that does not match any
> > gathered location data, this will be immediately stored and sent to
> > authorities in both the detected location and the entered location to
> > alert them of a citizen potentially trying to evade censorship
> > regulations. If the location entered requires further information,
> > such as whether an encryption license has been acquired, the user's
> > age, etc, it will be requested at this point. This process will also
> > be repeated every time a user account is created, and will require
> > implementation in both graphic and text-based account management
> > utilities, such as adduser.
> >
> > This location and user data will be managed by a new daemon,
> > systemd-censord, and stored in an encrypted form and otherwise
> > protected so as not to be readable or modifiable by any user on the
> > system. To ensure privacy, great care must be taken to prevent a user
> > from being able to access other users' personal information, and to
> > ensure compliance with censorship regulations, no user may be able to
> > change their location in any fashion which bypasses dedicated
> > utilities, which will perform the required location validation and
> > discrepancy authority notice functions when the user requests to change
> > their location, such as for moving house or travel.
> >
> > Systemd units will be created for every desired censorship function,
> > and will be started based on the user's location. For example, a unit
> > for Kazakhstan will implement the government-required backdoor, a unit
> > for China will implement keyword scans and web access blocks (more on
> > this later), a unit for Florida will ban all packages with "trans" in
> > the name (201 packages in current stable distribution), a unit for
> > Oklahoma will ensure all educational software is compliant with the
> > Christian Holy Bible, a unit for the entire United States will prevent
> > installation of any program capable of decoding DVD or BluRay media,
> > and a unit for California will provide the user's age to all
> > applications and all web sites from which applications may be
> > downloaded. As can be seen, multiple units may be started for a given
> > location.
> >
> > All communication will be over D-Bus, with each application proactively
> > asking systemd-censord for permission to perform any operations which
> > may foreseeably be restricted anywhere in the world. A standardized
> > list of permissions will need to be developed, as well as standard
> > personal data fields, such as user age. Blobs for the storage of media
> > player keys and digital rights management content could also be added
> > as additional functionality.
> >
> > Since keyword scanning and web filtering are extremely common
> > government interests, a dedicated daemon for this function should be
> > created, with kernel hooks to allow inspection of all internal program
> > structures as well as internet traffic. This daemon can then be
> > started with different filter configuration files for each systemd unit
> > triggered by the user's location. To comply with book bans common in
> > many US states, such as those restricting access to books on
> > LGBTQ[[:alnum:]]* topics or having non-white characters, this module
> > should also automatically search the filesystem for prohibited ebook
> > files.
> >
> > Many packages will need to be altered to include specific functionality
> > relevant to censorship, including dpkg. For example, installing tor
> > will be prohibited in many countries, and some packages, like
> > fortunes-off, will be restricted based on the user's age, as will most
> > games. Web browsers will have to be patched to send the user's age to
> > all websites hosting applications for download. Encryption packages
> > will have to check if a systemd unit limiting encryption strength is
> > running, and set their maximum key length, disable features, or send
> > private keys to a specified IP address determined by the unit.
> >
> > To prevent users from bypassing censorship requirements, debian will
> > need to switch to being a binary-only distribution with signed
> > binaries, signed kernel, and signed kernel modules, with mandatory
> > secureboot, and controls to prevent any non-signed software from being
> > installed, written, or compiled, as any foreign sources of software may
> > fail to query systemd-censord or may fail to respect the permissions it
> > returns.
> >
> > On the non-software side, the debian licenses will need to be modified
> > to disallow removal or alteration of any of these features by
> > derivative distributions – for example, no distribution will be allowed
> > to ship without systemd because then systemd-censord may not work
> > correctly. In addition, the licenses for all packaged software will
> > need to be amended to disallow removal of censorship functionality.
> >
> > As I'm sure is obvious, if debian is going to comply with government
> > censorship regulations, a universal framework allowing easy addition of
> > new rules will greatly reduce developer time over individual ad-hoc
> > implementations of each new freedom restriction. Complying with only
> > one regulation, such as California's attempts to prevent minors from
> > accessing unapproved information, makes no sense when there's hundreds
> > or thousands of other regulations not currently being complied with.
> > This framework should ensure all users get to experience their full
> > censorship regime no matter where they are in the world.
> >
> > Thanks for reading, and I hope we can work together to help Linux
> > implement as much censorship as possible!
> > --Floofy Wolf
>
> Nice work!
>
> I would agree with encrypting systemd-censord, but *how* to decrypt it, I
> have an idea for. It requires /etc/machine-id, AppArmor or SELinux, FDE,
> and a new *specially* compiled kernel module. Feel free to critique it
> and give me new ideas.
>
> Starting off, /etc/machine-id is generated upon new installations with
> systemd-firstboot, and it is unique to all systems. This means it can be
> used as a shared key along with a unique salt to prevent rainbow table
> attacks. This would be pretty bad for anyone to see publicly, so now we
> have to come up with a solution.
>
> My solution to this is FDE with TPM2, a kernel module, and an MAC.
> Firstly, all systems must have FDE with TPM2 from hereon. Any system that
> hasn't had it before is now an unsupported configuration. Secondly, the
> new kernel module is included in the initramfs so that it can start
> reading /etc/machine-id after root is mounted, but before any MAC can do
> anything to prevent it from being seen. Finally, the kernel module
> decrypts systemd-censord using the machine-id and salt, runs it, and
> encrypts it again. For good measure, AppArmor or SELinux would hide
> systemd-censord and the kernel modules.
>
> This is not fully concrete, but I believe this is a starting point. I am
> fully open to other ideas.
>
> Cheers,
>
> --
> Artur Manuel
> amadaluzia
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
