Add a policykit policy that allows yast to run via pkexec

[sp1ritCS]

I'd like to graphically execute yast with pkexec. This is currently not possible, as pkexec does not pass environment vars to the privileged process (similar to sudo without -E).

It is possible to define a policy that would allow yast to be run graphically. In comparison with sudo -E the org.freedesktop.policykit.exec.allow_gui only passes $DISPLAY and $XAUTHORITY. This causes yast to not honor qt and icon themes. (I have no experience with polkit, so I don't know if this can be fixed)

I've created a working (with above mentioned issues) policy.

/usr/share/polkit-1/actions/org.freedesktop.policykit.YaST.policy:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
	<action id="org.freedesktop.policykit.pkexec.YaST">
		<description>Run YaST</description>
		<message>Authentication is required to run YaST</message>
		<icon_name>yast-control-center</icon_name>
		<defaults>
			<allow_any>auth_admin</allow_any>
			<allow_inactive>auth_admin</allow_inactive>
			<allow_active>auth_admin</allow_active>
		</defaults>
		<annotate key="org.freedesktop.policykit.exec.path">/sbin/yast2</annotate>
		<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
	</action>
</policyconfig>

I'd love to see this integrated (maybe even with the desktop entries, as xdg-su/gnomesu is incredibly slow)

[kobliha]

Hi @sp1ritCS, thanks for the proposal.

I'd like to read more about your use-case, please. I've been checking a bit on difference between pkexec and the way which we use currently and from what I've seen, they are basically comparable. If I read this issue correctly, I feel that you want this because "xdg-su/gnomesu is incredibly slow"? Is that the only reason or is there something else which I don't see?

Thanks in advance

[kobliha]

BTW, some of the links I used:

• https://www.freedesktop.org/software/polkit/docs/0.105/pkexec.1.html
• https://unix.stackexchange.com/questions/203136/how-do-i-run-gui-applications-as-root-by-using-pkexec
• https://askubuntu.com/questions/78352/when-to-use-pkexec-vs-gksu-gksudo

[sp1ritCS]

Yes, it's supposed to do the same.

Is that the only reason or is there something else which I don't see?

Well, additinaly pkexec looks a lot better on gnome-shell than gnomesu. (afaik on plasma xdg-su looks the same as pk) and it works a lot better with fprintd.

[ancorgs]

I wonder if there is someone with a stronger security/polkit background in the openSUSE community that we could add to this discussion to tell us: (a) whether this approach is good in general, (b) whether the mentioned issues with icons and themes can be easily solved.

[ancorgs]

@msmeissn is my first option for security+(open)SUSE questions. Can you provide some guidance about this topic?

[msmeissn]

as i am on parental leave until May 10th, please refer to @jsegitz or @mgerstner

[jsegitz]

I added this as https://bugzilla.suse.com/show_bug.cgi?id=1183718 to our work queue. We'll also update here once we had a look

[mgerstner]

The policy is fine as long as it is fine to run graphical YaST as root. Since there exist other means to do this already security will not be worse than before.

Other packages use similar polkit policies and polkit is generally sane in this regard, the rest is up to the invoked application. Of course users need to be aware of the generally raised security attack surface when running graphical applications as root (especially in the X.org server, which is the target of this policy).

[MattSturgeon]

Running yast via polkit would greatly improve user experience personally.

I have polkit configured so that I enter the user's password (if the user is in group wheel).

// /etc/polkit-1/rules.d/40-default.rules
polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});

This means that I do not need to share a root password between all admins. In fact, my preference is to disable the root password entirely (e.g. via sudo passwd -l root).

This doesn't play well with xdg-su, as most implementations ask for the root password rather than the user's. The only exception I'm aware of is kdesu, which can be configured to use sudo instead of su.

gksudo would do the same thing for my specific use case, however I understand the consensus is that polkit is a better and more modern option. I also understand that polkit works better with libfprint.

I'm able to launch yast with polkit, however I cannot get yast to launch the qt GUI when run via polkit, it always opens the ncurses interface.

[shundhammer]

https://bugzilla.suse.com/show_bug.cgi?id=1216178

[MattSturgeon]

From 1216178

What problem is this trying to solve? This sounds like busywork for no real purpose at all.

Moving away from an su based approach solves a few issues; for me the biggest one is the need to have a root password. The system is far more secure when root cannot be logged into directly using a password. On systems with multiple wheel admins, applications prompting for a root password are a poor experience as those admins now need to remember both their own and root's password.

Moving to polkit additionally brings some modern niceties, such as fingerprint or smart key authentication, for example.
Polkit also shares some benefits with sudo-based solutions, such being able to use the admin's password instead of root's and being able to configure what actions require what kind of authentication.

Additionally, as 1216178 mentions, it's questionable whether xdg-su and gnomesu can be considered maintained.

The last thing on earth that we need is to debug people's botched configurations

This is reasonable. Realistically, I doubt many users will actually mess around significantly with their polkit config - that's something that a distro usually tries to ship with sane defaults - but I appreciate we don't have to agree on this point.

That said, if we follow this argument to it's logical extreme, you eventually end up removing all configuration options that have the potential to break a system; simply because you do not trust users not to waste your time with their botched configs.
Yes, this is a bit hyperbolic; I'm just trying to emphasis that polkit isn't the only thing that has config options.

---

While I think it's a shame that issue was closed so dismissively as a WONTFIX, I fully appreciate you have many more pressing tasks and issues. This comment is simply an attempt at conveying my personal perspective.

[shundhammer]

This kind of thing is always a balancing act between a powerful permission system that can be fine-tuned with very high granularity and being idiot-proof (there is no such thing) reasonably stable against users exploring the system more than is good for them.

Back in a prior life, many decades ago (as a matter of fact, in the last millenium), I was part of a project design team where we created a distributed client-server system for university clinics; for radiology images (X-rays, CTs, MRTs etc.) as well as for scanned paper documents. We were young and allowed feature creep to extend the original mission, and so we found ourselves designing a system that spanned many levels of users (doctors, nurses, medical-technical assistants, administrative clerks) as well as all areas of a university clinic; from medical wards to surgery to specialized radiology departments to the hospital administration.

So we needed fine-grained permissions; because only some personnell is allowed access to sensitive data in some areas, and in general some departments should only have localized access.

So we added very granular permission policies; things like "permission to open a patient's folder", "permission to open a radiology folder", "permission to modify a patient's personal data", "permission to view a radiology image", "permission to view a letter from the patient's family doctor" etc.; very fine-grained.

And of course there were users and departments etc. in a hierarchy, and roles that a user could get within that hierarchy like "doctor", "nurse", "medical technical assistant".

We believed that this granularity was appropriate; of course we were aware that the vector product of all those dimensions would lead to a lot of permutations. But we also knew that it would lead to the requested flexibility with permissions.

But we grossly underestimated how quickly the human mind, even of the brightest system administrator, is boggled. And not only were they boggled, they were hyper-boggled.

We kept getting a gazillion bug reports (or rather, phone calls; because there was no such thing as the WWW back then or a bug tracker like Bugzilla) that user XY needed access to this and that, and couldn't get it. And we had to track down each individual case to spot the problem; which micro-permission the user actually needed for that task, which the admin had overlooked and not granted him.

It was a mess. And it didn't take long until the admins gave up and granted very generous permissions; because that was the only way to keep department heads off their backs because their people couldn't do their work.

So in the end, after all this trouble and good intentions, it all fell back to very coarse permissions on the level of "big boss" vs. "lowly clerk". But of course all the complexity was still in the code, in the administrative interfaces, in the design, in the concept. Once you let that ghost out of the bottle, there is no getting it back inside.

[shundhammer]

So, if we did this for YaST, how would we do it?

Just a coarse permissions scheme on the level of "may use the software module"? That sounds too coarse.

It would probably more be something like "may install additional packages", "may uninstall packages", "may upgrade packages". What about adding, removing, disabling, enabling repos? About changing a repo's URL?

What about allowing a vendor change for one or more packages? And if so, for system packages, too?

If we deny a user permission to install additional packages, but grant that user permission to start certain configuration modules, and that "YaST FooBar Config" module (that he has permission to use) upon startup detects that it really needs to install the low-level "foobar-tools" package which requires "libfoobar", can that user continue (i.e. do we grant him permission to install those packages if needed), or is the user now stopped dead in his tracks?

If we grant a user permission to configure system services like ssh / sshd, but that would require opening the ssh port in the firewall, can that user continue despite not having permission to modify the firewall?

Etc. etc.; you get the picture.

In general, a system administration tool like YaST is much more complex than most users think, and that affects the required permissions. For the average user, it's pretty much impossible to get even a rough overview of all the little things that need to be done even for seemingly small sysadmin tasks.

And we also don't want to expose that complexity; not even mentioning that many of that are implementation details that are subject to change.

If you ever used the AppArmor tools and you were surprised what weird files and commands even mundane tools are using on a regular basis, you only saw a glimpse of what that would mean for YaST. And even if you tried to put one single YaST module into an AppArmor jail, you would probably miss dozens of uncommon cases, making them unusable. And it would be very similar with a fine-grained permission system.

Now imagine that we would add such a fine-grained permission system to YaST, and we would ship it with reasonably liberal default permissions. And then curious users would start tinkering. Would they? Of course they would. Because they can; because that's the Linux spirit.

How long would it take until our exploring user would lock himself out of some of the parts of YaST? And how long would it take until he would notice such a lock-out? Because it's not always immediately apparent. A permission might be needed only in certain exotic cases; but then it would be needed badly.

Such as in the two examples above with the need to install more packages on the fly when starting a YaST configuration module for the first time. Or when the need arises to open or close a port in the firewall. Or when the video player needs another codec from PackMan. Or in a gazillion other cases.

So, what would be a strategy to recover from such a situation? A brute-force tool to reset all permissions to (permissive) defaults and throw away all the tinkering? Wouldn't that be a bypass of that complete permission system, making the whole thing completely pointless, just a giant waste of time and effort?

And how many times would such an exploring user not even be aware why the sysadmin task that he wanted to do didn't work? Would he really relate that to that permissions change from three weeks ago?

I bet a good part of such users would furiously write bug reports, venting all pent-up frustration of all the things they feel wrong with YaST.

And then good luck analyzing the problem and finding the missing permission and the trace of that YaST session three weeks ago when the permission was changed.

No, sorry, we don't need that.

And I am also sure that the vast majority of our users is better off with what it is right now: A crude, but simple and easy-to-understand permission system. You either have root privileges or you don't.

[shundhammer]

And BTW the need to enter the root password is no longer an issue with this:

Once:

sudo visudo

Edit this line to add DISPLAY to the environment variables to keep:

Defaults env_keep = "... DISPLAY"

Uncomment this line to ask for your password, not the root password:

# Defaults targetpw

From then on:

xhost +
sudo yast2

[MattSturgeon]

I don't dispute any of your arguments for keeping complexity low, but I think you're inflating the scope of this issue a little.

EDIT: I actually think most of your arguments against polkit apply more broardly to whether openSUSE should support polkit at all. That ship has sailed, however; openSUSE (like most distros) already enables polkit by default.

This issue isn't about adding fine-grained permissions via polkit. It simply states:

I'd like to graphically execute yast with pkexec.

The issue then proposes a solution, a simple policy file. The polkit policy was later reviewed by @mgerstner who stated:

The policy is fine as long as it is fine to run graphical YaST as root. Since there exist other means to do this already security will not be worse than before.

Increasing security by not running YaST's gui as root is out of scope of this issue (that's covered by #1293). This issue is simply about enabling YaST's QT interface to be run using pkexec, with the "stretch goal" of changing from xdg-su to pkexec in the .desktop files by default.

As far as I can tell, allowing users to execute YaST using their choice of su, sudo, xdg-su, or pkexec has effectively no downsides; the only caveat being you have to maintain one additional config file to do so.

[shundhammer]

As I wrote in bsc#1216178, it's not too hard to replace our existing YaST Qt Control Center (package yast2-control-center-qt) with something else that uses pkexec instead. That control center is a very simplistic Qt application that is just a launcher for YaST modules. It's not very pretty, it's old code, and it shows its age. It might be overdue for a replacement.

Modifying every single one of all the YaST .desktop files is another matter, though, since they are owned and maintained in each individual source repository; and not all of them are public or maintained by the YaST team.

That's why I suggested to do an implicit replace in an alternative control center of s/xdg-su/pkexec/.

[TobiPeterG]

For everyone interested: I branched all current yast modules in Factory and patched them to use polkit instead of xdg-su
You can find the project here:
https://build.opensuse.org/project/show/home:Tobi_Peter:yast2-polkit

It seems to work just fine, but my testing has been limited. So should anything go wrong, it's not my fault ;)