There are no plans for anything in Haiku at the moment, besides “fix bugs and release R1”. Other things happen if people decide to work on it.
For drive encryption, your best bet would be https://github.com/axeld/driveencryption but it needs some work to integrate it with the launch server and the package system.
For screen lock, as extrowerk said, the closest you can get currently is the password-protected screensaver. It is not very difficult to escape, however (for example by rebooting the computer). It may not be too hard to add something to autolock the screen at boot (instead of going to the desktop). Still it would not be perfect, but it would be slightly better.
I have used the screensaver in autostart for some months already on a few devices.
I can’t recommend it at the moment.
Sometimes it locks,sometimes it doesn’t and you get to the desktop after a boot.
Additionally,you can open the start menu using the keyboard shortcut while the screen is locked (that’s a known issue).
Achieving this is much easier now that Haiku has the launch_daemon than it was before. Of course the launch_daemon was added some time ago, and no one has made a login system yet, but as PulkoMandy says there have been other priorities.
But right now the launch_daemon calls something called autologin to start the user session and in theory that could be replaced with something that checks a password. That would be a good first step.
As far as I know one of the reasons Axel added the launch_daemon for the purpose of being able to handle encrypted drives, so that should also be doable. I think there are some other forum topics where that is discussed.
Anyone with a bit of programming skill could start experimenting with this on their own since the launch_daemon is driven by configuration files.
It calls getpwuid for user 0 and then passes that username to BLaunchRoster().StartSession(). The one thing I’m not sure of is the state of app_server at this point so whether a graphical login is possible. Axel or someone else might know. I’m interested in exploring this but likely won’t have any time soon.
We already have a login screen in Haiku sources. But that’s not the hard part. The hard part is making sure there is no easy way to avoid that screen (pressing control alt del and killing it from TeamMonitor and clicking “Restart Tracker”, for example). Otherwise it doesn’t really help securing the machine.
dm-crypt is a transparent disk encryption subsystem in Linux kernel v2.6+ and later and DragonFly BSD. It can encrypt whole disks, removable media, partitions, software RAID volumes, logical volumes, and files.
The encryption is the “easy” part in this case. Most of the work is turning it into an Haiku driver, and integrating it with the userspace side (asking the user for a password, making sure the encrypted partition is mounted early at boot if you want to store your home directory or even the whole system in it, etc). Not a lot of this is easily ported from another OS.
If you don’t need to encrypt your OS and home directory, driveencryption is already working. You have to use it on a separate disk where you store all your secret data at the moment. This is not perfect because for example browser cookies and history can’t easily be moved there, moving the bash history needs some tricks, etc. Ideally it would be usable to encrypt at least a home partition.
As PulkoMandy correctly remembered in another thread, I wrote the launch_daemon primarily to solve the issue that, with package management, there was no simple way to influence the system startup in a way to make this possible. Before that, I already had my laptop set up in a way that it would start “Login” (from DriveEncryption), and automatically mount an encrypted volume during the login.
However, I never got around to actually update the Login application to do this. It would just need to call BLaunchRoster::StartSession(), too. More app_server support is not needed here (if I recall correctly, otherwise, I might have messed it up, too :-)).
I just don’t know the flow very well, I wasn’t sure if autologin was called after app_server was running or before. I know there has been some discussion about per user app_server instances, though maybe that is not how it works now.
If the registrar and app_server are running but nothing else a login application can present a GUI and then I don’t think we have to worry much about someone bypassing it, except maybe the Vulcan death grip to start the Team Monitor. Though I forget what handles that…
Anyhow I probably should spend more time using Haiku again to explore this
Edit: OK, input_server handles the Team Monitor, which makes sense.