[Impact]
Potential security issues in ApplyPolicy due to race when scripts are enabled.
[Test Plan]
1. Attach your machine to Ubuntu Advantage to get script support.
2. Add a script to one GPO for user login/logout
3. Login as an user, starting a new user session (no session should be currently running for that given user).
4. Check the permissions are following what is described from the discussion below.
[Where problems could occur]
Script support was added recently, and it needs Ubuntu Advantage enablement to be activated. However, to this day, there is still no official ubuntu-advantage-desktop-daemon packaged on focal.
----
./internal/policies/scripts/scripts.go ApplyPolicy() unsafe owner changes:
Changing the scripts directory owner allows any user processes to create
symbolic links within, and then they can take ownership of any file on
writable mounts.
If the files must be owned by the user, the best way is to switch to the
user's uid before creating the files. fchown(2) of the file descriptor
before closing it should also work.
I lose track of what's happening around the "Running machine startup
scripts" -- it looks to me like adsys is also *executing* the scripts that
were moments ago given to the user to modify. It is not safe for root to run
user-owned files.
Does the user *have* to own the directory and scripts?
Thanks
Thanks for raising this, I don’t really understand the implication of the directory change as then, any user process can create things in that directory, but as this directory is only then dealt by user process, this is fine?
Let me explain to you what happens to user scripts:
- adsysd get the policies, and for each user, copy the scripts in their own directory, with the UID of the user so that they will be to execute it. Note that machine scripts won’t change any UID. If the directory already exists, nothing is done (that prevents refreshing machine scripts until log off, see below).
- then, on log on, there is a systemd user script which execute "adsysd run-scripts", a separate process, as the user thus, which takes that directory and executes all scripts one after another, as the user
- finally, on log off, the systemd service will stop, and ExecStop will rerun adsysd run-scripts, still as the user, but for logoff (the script list may be different). Then, it will delete the user directory.
-> That way, next logon, adsys will reinstall new version (or maybe the same that were cache) scripts, ready to be executed.
So, we need to delete that directory on logoff. This directory will never have scripts executed as root (apart from machine scripts, which is totally different as we don’t change the owner for them). And anyway, those scripts are executed by a systemd job, not by the adsysd "root" daemon itself.
Does it make sense? Happy to have a chat to:
1. Understand the security issue (let’s use this to learn something, especially dark corners of security :p)
2. To see how we can safely fullfil our needs.