Security and User Accounts

What is it?

This roadmap turns Impossible OS from a single all-powerful user into a multi-user system: user accounts with hashed passwords, a sign-in screen, a Win+L lock screen, user switching, per-user file permissions and a consent prompt before a program gains administrator rights. The kernel security primitives it builds on have shipped (random numbers, password-hashing code, access tokens and privileges), but nothing a user would see has: there are no accounts, no sign-in and no lock screen. The first section is in progress because its only remaining item is to confirm the kernel random number generator is the one consumed.

How does it work?

Today. Everything runs as one user, and nothing asks who you are.

• Random numbers. The kernel CSPRNG is ChaCha20 with fast key erasure, seeded at boot from RDRAND, the TSC, the ACPI timer, jitter, the TPM and the loader's seed (csprng.c). csprng_fill() and csprng_u64() serve kernel callers, csprng_crypto_ok() says whether it is seeded well enough to make keys, and NtGetRandom serves user programs (csprng.h). The seeding is described in Early Entropy and Random Seed.
• Password hashing. Monocypher 4.0.2 is vendored and built, including crypto_argon2() with the Argon2d, Argon2i and Argon2id variants (monocypher.h). Only a kernel self-test calls it today.
• Tokens and privileges. Every task carries an access token. Task 0 gets the SYSTEM token with all privileges, and new tasks copy their creator's, so every program runs as SYSTEM (token.c). SeCreateUserToken() can build a standard or administrator user token but has no caller outside the tests. 25 privileges are defined (privileges.c), and some are enforced: shutdown and reboot need SeShutdownPrivilege, setting the clock needs SeSystemtimePrivilege. The whole model is described in Security Reference Monitor.
• Registry. HKU\Default holds the one profile (home folder C:\Users\Default, shell C:\cmd.exe, wallpaper), and HKEY_CURRENT_USER always resolves to it because nothing calls reg_set_current_user() (registry.c).
• File permissions. IXFS stores an owner, a group and Unix-style read, write and execute bits on each inode, and ixfs_check_perm() checks read and write for a user and group (ixfs_format.c, ixfs.h). Nothing calls it, and new files are owned by user 0.
• Shutdown. The Start menu's power button calls acpi_shutdown() directly instead of the privilege-checked shutdown call (desktop.c); rerouting it is an open item in the login screen section.

Planned design.

1. CSPRNG. Consume the kernel generator; the roadmap's own pool was retired.
2. Password hashing. auth_hash_password() and auth_verify_password() on Argon2 with a random salt.
3. Accounts. A user record in the Registry, with an Administrator and a Guest created on first boot.
4. Authentication. auth_login() and auth_logout(), loading the user's HKU\{name} hive, with a 30-second lockout after five failures.
5. Home folders. C:\Users\{name} with Desktop, Documents, Pictures, Music and Downloads, owned by the user.
6. Sign-in screen and 7. Sign-in flow. A full-screen acrylic screen with a 192 pixel avatar and a masked password box, per the lock and sign-in design, then avatars for each user, a shake on a wrong password and optional automatic sign-in.
7. Lock screen. Win+L blurs the desktop and asks for the password to resume.
8. User switching. Sign out and switch user from the Start menu.
9. File permissions. ixfs_check_perm() enforced on open, write and execute.
10. Elevation. A consent dialog that grants a program administrator rights for the life of that process.

What are its interfaces?

How do I use it?

It cannot be used yet. The system starts straight to the desktop as the default user.

What is not implemented yet?

• CSPRNG (in progress) and Password Hashing
• User Account System, Authentication API and User Home Directories
• Login Screen UI and Login Flow
• Lock Screen and User Switching
• File Permissions
• UAC-Equivalent Elevation, which may use the kernel's filtered-token elevation once UAC and token filtering ships

How does it compare with Windows 11 and Linux?

Windows 11 has SAM and domain accounts with SIDs and full access control lists, Windows Hello and PIN sign-in, the Win+L lock screen, NTFS permissions and the UAC prompt with integrity levels. Linux uses /etc/passwd and /etc/shadow with yescrypt or SHA-512 hashes through PAM, display managers such as GDM and SDDM, loginctl lock-session, rwx bits plus ACLs, and sudo or PolicyKit for elevation. Impossible OS has the kernel token model already but only one user. The plan hashes passwords with Argon2, stores accounts in the Registry, and reuses the IXFS permission bits without changing the inode format.

See also

• Security and User Accounts roadmap
• Security Reference Monitor
• Early Entropy and Random Seed
• Kernel Libraries
• IXFS Core
• CNG Crypto and Certificate Store