search

bit-team / backintime

Back In Time - An easy-to-use backup tool for GNU Linux using rsync in the back
https://backintime.readthedocs.io
GNU General Public License v2.0
2.03k stars 201 forks source link

[Arch, Manjaro] Error when running as root: PolicyKit points to /usr/sbin/nice #931

Open ghost opened 6 years ago

ghost commented 6 years ago

Could someone shed some light on what this error is about, I'm trying to run it as root.

net.launchpad.backintime.InvalidCmd: Parameter 'cmd' contains non-whitelisted cmd/parameter (/bin/nice)

Thanks!

ghost commented 6 years ago

I've found that this error only occurs when I try and configure it to backup automatically when the drive is plugged in. If I use a fixed interval or on boot instead, I don't get an error.

bachy commented 4 years ago

i have the exact same error on arch, how can i help to fix this ?

mcku commented 4 years ago

try disabling "nice" options in the options tab

brummer-simon commented 2 years ago

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

wgranicki commented 2 years ago

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Same problem here

buhtz commented 2 years ago

Thanks for reporting the issue.

Please give detailed information's about

If possible please give us the full debug output (use --debug option when starting BiT).

Tell us the steps to reproduce that error.

Thanks in advance.

wgranicki commented 2 years ago

My setup:

Steps to reproduce:

Log (using --debug option): https://pastebin.com/mErzUr0R

Edit to add: problem does not occur with any of the other scheduling options selected.

buhtz commented 2 years ago

Thanks for the information's. This is related to D-Bus which I'm not experienced with.

https://github.com/bit-team/backintime/blob/29e874f5080f7cf85c8297ea807cb8070a427c10/common/tools.py#L1733

wgranicki commented 2 years ago

I think the problem is here https://github.com/bit-team/backintime/blob/29e874f5080f7cf85c8297ea807cb8070a427c10/qt/serviceHelper.py#L104

If I understand it correctly, only nice and /usr/bin/nice are accepted (whitelisted) as outputs of which, but in my case it's /usr/sbin/nice

buhtz commented 2 years ago

If I understand it correctly, only nice and /usr/bin/nice are accepted (whitelisted) as outputs of which, but in my case it's /usr/sbin/nice

Makes sense. sbin is for super-user only. Maybe Manjaro allow nice for root only?

I ask myself if we need nice at this point?

And I also ask if Manjaro offers a way to use nice in our case?

From @brummer-simon

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Why does backintime appear in /usr/sbin? It definitely should not. How did you install it?

@wgranicki What does whereis backintime say on your system? Looking back into your debug output... DEBUG: [common/backintime.py:670 getConfig] config file: /root/.config/backintime/config Because of the location of that config file I assume you run BiT as root?

wgranicki commented 2 years ago

I don't think it's a Manjaro problem, because there's also /usr/bin/nice present. But I'm running BIT as root, because I want to backup the whole system, and not just the parts accessible to my user.

wgranicki commented 2 years ago

Why does backintime appear in /usr/sbin? It definitely should not. How did you install it?

It appears both in /usr/bin and /usr/sbin, because the latter is just a symlink to the former. As I said before, I installed it from the official Manjaro repository via pacman

Also, I tried disabling using nice in the Advanced settings tab, but then it complains similarly about ionice. Disabling ionice leads to /usr/sbin/backintime error as per @brummer-simon's comment

All of this seems quite strange, because neither which nor whereis report the /usr/sbin/ locations - regardless if run as root or not. But somehow BIT finds those and throws exceptions.

emtiu commented 2 years ago

Thanks for your reporting and testing. I can reproduce the error on a virtual Manjaro 21.3.7 installation.

It's a total mystery to me why the system tries to use /usr/sbin/nice, especially since /usr/sbin is just a symlink:

[manjaro@manjaro ~]$ ls -ld /usr/sbin
lrwxrwxrwx 1 root root 3  9. Jun 09:53 /usr/sbin -> bin

As far as I can see, this is different on Debian and Ubuntu, so we are dealing with some sort of Manjaro specialty here.

A dirty workaround would be to include /usr/sbin/nice in the whitelist, but @brummer-simon has indicated that this might not even eliminate all problems:

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Also, I see the same confusing behavior as reported by @wgranicki:

All of this seems quite strange, because neither which nor whereis report the /usr/sbin/ locations - regardless if run as root or not. But somehow BIT finds those and throws exceptions.

So, the prize question is: Why does backintime, on Manjaro, try to use binaries from /usr/sbin (such as /usr/sbin/nice) when run as root?

buhtz commented 2 years ago

My Debian doesn't have a /usr/sbin/nice.

Maybe Manjor whereis always sort the entries descending by there user rights.

In the reported case BiT run as root so the sbin folder is used instead.

emtiu commented 2 years ago

Maybe Manjor whereis always sort the entries descending by there user rights.

In the reported case BiT run as root so the sbin folder is used instead.

It's not quite so simple, because on the terminal, whereis nice does not point to a /usr/sbin location (and neither do other tools):

[manjaro ~]# whereis nice
nice: /usr/bin/nice /usr/include/nice [...]
[manjaro ~]# which nice
/usr/bin/nice
[manjaro ~]# type nice
nice is /usr/bin/nice

My best guess is that the reason is hidden in some place where Manjaro and Python meet (like default paths in the sys or os modules, or something).

buhtz commented 2 years ago

Did you tried to run whereis nice via sudo and as root (sudo su)?

I see this code and would say bit does nothing less then just call whereis nice but as root.

My best guess is that the reason is hidden in some place where Manjaro and Python meet (like default paths in the sys or os modules, or something).

I don't think so because bit don't use python stuff to find nice but just call whereis on a shell.

wgranicki commented 2 years ago

I have tested it in all three variants: as regular user, with sudo and as root. Every time the results are the same, and they never include the symlinked sbin, only /usr/bin/nice

buhtz commented 2 years ago

Good reason for me to create a Manjaro machine...

emtiu commented 2 years ago

You're both right, and I've gotten one step closer to the root (hah!) of the problem.

  1. The problem does not occur when running sudo backintime-qt. Also, sudo which nice returns /usr/bin/nice, as expected.
  2. The problem does not occur from a root shell called by sudo su (or just su). Also, which nice called from this root shell returns /usr/bin/nice, as expected.
  3. But, the problem does occur when running Manjaro's "Back In Time (root)" application from the Desktop Environment's menus.

So, I investigated the last case. The menu application calls /usr/bin/backintime-qt_polkit, and this is a script which ultimately calls: pkexec [...] /usr/bin/backintime-qt

So when backintime is run as root from the application menu, it's not sudo that's involved with the elevated privileges, but PolicyKit's pkexec. And here's the smoking gun:

$ pkexec which nice
/usr/sbin/nice

So there, it's PolicyKit deciding that /usr/sbin should be the prefix for whatever's happening, and thus colliding with backintime's whitelist containing /usr/bin/nice only.

For the moment, I don't have a good idea what to do about that ;)

wgranicki commented 2 years ago

Just in case, I also tested running Popen(['which', 'nice'], stdout = PIPE).communicate()[0].strip().decode() in Python console (again as regular user, with sudo and as root) and the results are the same as before.

I confirm, that it's definitely pkexec's fault:

$ pkexec which nice
/usr/sbin/nice
emtiu commented 2 years ago

From a quick test, it looks like in Ubuntu (and probably Debian), pkexec works similarly – but /usr/bin and /usr/sbin are actually separate folders.

Therefore, pkexec nice [program] only suggests executables in /usr/sbin if they really exist there.

$ pkexec which nice
/usr/bin/nice
$ pkexec which fsck
/usr/sbin/fsck

This makes me think that it's a bad design decision by Manjaro to symlink /usr/sbin to /usr/bin, but there's nothing backintime can do about that.

buhtz commented 2 years ago

Maybe we can question why BIT needs nice and if it can't use /usr/bin/nice by default on all systems not matter if run as root or user. I don't understand the background here.

If not this should be reported to Manjaro. Maybe they have a better idea.

wgranicki commented 2 years ago

This makes me think that it's a bad design decision by Manjaro to symlink /usr/sbin to /usr/bin

I don't think that's a bad decision in itself... But combined with this ↓ it creates the mess we see

$ pkexec env | grep PATH
PATH=/usr/sbin:/usr/bin:/sbin:/bin:/root/bin

I don't agree with your statement, that

there's nothing backintime can do about that.

I see at least two options here:

noyannus commented 1 year ago

I have the same Issue and disabling "nice" doesn't help because the next the invalid command complains is "/usr/sbin/backintime". I'll resort to creating backups based on an interval. If you need move details on the issue feel free to contact me.

Same problem here

Still a problem. After disabling nice and ionice appears the "non-whitelisted command/parameter" /usr/sbin/backintime dialog.

backintime-qt 1.3.3-1
backintime 1.3.3-1 Both installed from Manjaro "Community" repo (can't remember which package manager).

Operating System: Manjaro Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-1-MANJARO (64-bit) Graphics Platform: X11

buhtz commented 1 year ago

Please open a ticket at Manjaro and/or Arch about it and leave us a link here. Because it seems to be Manjaro specific I would like to hear there expertise and opinion about it.

noyannus commented 1 year ago

Manjaro post.

yochananmarqos commented 1 year ago

@buhtz Manjaro packager here. Please define how this issue is specific to Arch / Manjaro. I skimmed through this issue since it was brought to my attention on the Manjaro forum, but it's very hard to follow.

If there's something to be done packaging-wise, I'm happy to do it.

The Manjaro backintime split package can be found on our GitLab.

By the way, I follow Fedora more than I do the AUR package.

emtiu commented 1 year ago

Please define how this issue is specific to Arch / Manjaro.

Thanks for coming in :) Here's what's happening:

  1. Manjaro has /usr/sbin symlinked to /usr/bin.
  2. Running the "BackInTime (root)" application uses pkexec to elevate permissions.
  3. Under pkexec, paths are configured such that which foo returns /usr/sbin/foo if it exists. Else, it returns /usr/bin/foo.
  4. backintime looks for the nice executable by calling which nice, but it's configured to only ever allow /usr/bin/nice as the answer. Else, the abovementioned Exception is thrown.

Now, if you run "BackInTime (root)" on Manjaro, the following things happen: 2 leads to 3, which leads to which nice returning /usr/sbin/nice because of 1, which leads to 4.

My best guess as to why this happened is that:

yochananmarqos commented 1 year ago

In summary, it's not a Manjaro issue then. As it seems you are aware, Manjaro inherits almost everything from Arch.

Why would the same thing not happen on Fedora, for example? Arch-based distros are not the only ones that don't use /usr/sbin/.

emtiu commented 1 year ago

Well, if nothing changes on the distro and packaging side of things, our best way to keep "BackInTime (root)" working on Arch and Manjaro is probably to do one of the things that @wgranicki suggested:

I see at least two options here:

  • whitelist /usr/sbin/nice (probably also /bin/nice and /sbin/nice), not just /usr/bin/nice
  • modify the script to just check if nice is available on the system instead of verifying (whitelisting) the full path, or parse the output of which for *bin/nice

Any opinions on the best way forward?

yochananmarqos commented 1 year ago

Well, I can't do anything on the packaging end unless I patched upstream code. I'm not a programmer, so I won't be doing that unless there's a good PR that could resolve it.

aryoda commented 1 year ago
  • whitelist /usr/sbin/nice (probably also /bin/nice and /sbin/nice), not just /usr/bin/nice

I vote for implementing this option since the underlying code was introduced in 2017 (https://github.com/bit-team/backintime/commit/42b2e003ae43f89bccb369d92ce7f4b78f7ca520) to fix a highly critical CVE in the service helper (which runs with elevated rights) and allowed arbitrary arguments and is now too restrictive in above edge cases.

The package maintainers cannot fix this decently (without e.g. playing with the path env var when starting BiT which I'd consider really dirty) so it is to us to fix this.

Generally (out of scope here): Our current dbus service helper is IMHO a security risk and modifying udev rules should be done without a permanently running daemon with elevated rights but by asking for elevated rights for backintime-qt only when the user wants to change the udev rules...

buhtz commented 1 year ago

Just for my learning: What does whitelisting technically mean in the context of this Issue?

emtiu commented 1 year ago

I'm not sure if it's a standard technique, but backintime does it like this: It is configured to run which nice, but only accepts /usr/bin/nice as an answer. If an attacker had modified paths so that which nice pointed to /tmp/nice, for example, then backintime would refuse to run /tmp/nice.

In this case, it is biting us in the ass, because through a chain of unfortunate circumstances, Arch and Manjaro create the illusion that /usr/sbin/nice exists, even though it doesn't really – and backintime refuses to run that, because it only accepts /usr/bin/nice.

The current best idea for a fix is to expand the whitelist, so that /usr/sbin/nice will also be accepted.