You are not logged in.
What is the default permissions for /usr/lib? Right now for me that entire folder is set to owned by my user.
I'm not sure what has happened, I haven't run anything recently other that the strap.sh script from BlackArch.
This is the error I keep getting:
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
sudo: fatal error, unable to load pluginsAt first I was getting an error about /etc/sudo.conf needing to be owned by uid 0 and /usr/bin/sudo needing to be owned by uid 0 and have the setuid bit set, I fixed that by logging in as root and making the necessary adjustments.
However, even though I wish to fix this I am far more concerned with why it happened in the first place. What could possibly cause this?
Last edited by medicineman2500 (2022-01-27 19:23:15)
Offline
I haven't run anything recently other that the strap.sh script from BlackArch.
... What could possibly cause this?
Asked and answered. Did you review that script before you ran it? I assume you ran it as root or w/ sudo?
Black Arch is known as a set of penetration testing tools, and the first test is if you follow their advice on installation, then you have failed the first penetration test.
Last edited by Trilby (2022-01-27 19:31:55)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
medicineman2500 wrote:I haven't run anything recently other that the strap.sh script from BlackArch.
... What could possibly cause this?Asked and answered. Did you review that script before you ran it? I assume you ran it as root or w/ sudo?
Black Arch is known as a set of penetration testing tools, and the first test is if you follow their advice on installation, then you have failed the first penetration test.
Wait no sorry, I ran that inside a VM not on my main pc... was wondering why I couldn't find the file...
Offline
So to my original question... what is the default of /usr/lib and while I'm at it: how do I check that the permissions across my system are as they are supposed to be?
Actually it appears that some odd directories in root are also set to be owned by my user... like srv, mnt etc... does this mean I've been hacked?
Last edited by medicineman2500 (2022-01-27 19:51:37)
Offline
LC_ALL=C sudo pacman -Qkk | grep -v ', 0 altered files'Edit:
stat /usr/lib/sudo/sudoers.soAnd I guess if you look into your bash history, youll find sth. like "chmod -R" or "chown -R" there and maybe a stray blank in "/ home/user"…
Last edited by seth (2022-01-27 20:31:42)
Offline
does this mean I've been hacked?
Huh? A malicious hacker broke into your system to assign ownership of root directories ... to you? All while leaving obvious signs of their work behind.
No, definitely not a hack. Just the result of doing something unsafe / unwise (which is why I suspected the blackarch script as they advise people to "curl" an unknown url and pipe to a root shell to be run without thinking ... absolutely horrific advice for / from anyone, made even more ridiculous given that it's from a group claiming to be able to help you learn about security).
Last edited by Trilby (2022-01-27 22:48:51)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
medicineman2500 wrote:does this mean I've been hacked?
Huh? A malicious hacker broke into your system to assign ownership of root directories ... to you? All while leaving obvious signs of their work behind.
No, definitely not a hack. Just the result of doing something unsafe / unwise (which is why I suspected the blackarch script as they advise people to "curl" an unknown url and pipe to a root shell to be run without thinking ... absolutely horrific advice for / from anyone, made even more ridiculous given that it's from a group claiming to be able to help you learn about security).
Agreed that does seem unlikely at first, but an elevated user is still elevated. I know I've done some funky things to get access... I'm running Monero and BOINC so it seemed like a possibility however unlikely.
It is horrendous advice, I haven't used their system in a while... I find their approach and philosophy to be offensive... but I just install what I need and leave it at that. Incidentally, the recent community cleanup has broken everyone's installation so lucky I didn't go that route on my VM!
Ok so I found the problem: I somehow mounted my root partition on /home/<user>/<dir> through fstab, which has obviously then applied the requisite permissions. Not sure how I did that but I definitely won't be using UUIDs again for non-system mounts jic I make this dumb error again.
Unfortunately it doesn't appear as though removing that entry and mount to / reapplies the proper permissions. Unless someone has any ideas I'm just going to nuke it and start again.
Offline
LC_ALL=C sudo pacman -Qkk | grep -v ', 0 altered files'Edit:
stat /usr/lib/sudo/sudoers.soAnd I guess if you look into your bash history, youll find sth. like "chmod -R" or "chown -R" there and maybe a stray blank in "/ home/user"…
Yeh I checked that as well and could see all my recent manaul mounts, all were done correctly.
Ok cool I'll run through that altered files thing and see what comes up.
Offline
Nuked it and now posting from the rebuilt system.
This seems like it shouldn't happen. I shouldn't have entire swathes of system files and directories change permissions simply by remounting my root partition on a user's sub directory. At the very least it should be a simple fix to remove this mount, reboot the system and have the root partition mount on / which should then apply the appropriate permissions.
Currently that is not the case, curious to know if there is a reason for this and if it's a suitable candidate for a bug report. Admittedly, not a high priority as this is the first time in nearly ten years of using Arch that I've made such a mistake but I could just as easily do it again. A security issue waiting to happen no?
Offline
Without seeing your shell history from the now-nuked installation it's impossible to tell what caused it put PEBKAC wouldn't be unheard of.
That's why seth asked you to look at it in post #5.
Offline
Without seeing your shell history from the now-nuked installation it's impossible to tell what caused it put PEBKAC wouldn't be unheard of.
That's why seth asked you to look at it in post #5.
Yeh.. no I know what happened. I made an entry in /etc/fstab intending to mount an external drive on a subdir in my home folder, instead I inadvertantly used the root partition's UUID. This meant that the root partition was remounted onto that user subdir.
Offline
Yes, I got that. But it doesn't explain how the permissions got changed, this doesn't happen by just mounting a directory somewhere else as permissions are not inherited automatically.
Offline
Ok so I found the problem: I somehow mounted my root partition on /home/<user>/<dir> through fstab, which has obviously then applied the requisite permissions.
That and a "sudo chown -R medicineman2500:medicineman2500 ~" would have done…
Offline
Yes, I got that. But it doesn't explain how the permissions got changed, this doesn't happen by just mounting a directory somewhere else as permissions are not inherited automatically.
Ah ok I see... quite odd, I definitely didn't do that. This was a fresh system not a week old and I only ever use one terminal so my history doesn't get jumbled.
Ok so I found the problem: I somehow mounted my root partition on /home/<user>/<dir> through fstab, which has obviously then applied the requisite permissions.
That and a "sudo chown -R medicineman2500:medicineman2500 ~" would have done…
And I couldn't find anything like a misplaced chmod/chown, I'm extremely careful when applying permissions but even root directories were affected. Very odd indeed.
Last edited by medicineman2500 (2022-01-28 13:39:38)
Offline