| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
 Posted: Sat Dec 20, 2014 10:27 am Post subject: |
 |
|
From the sudoers file, which is probably what they're using
| Code: | # Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
# Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL |
If you're going to leave wheel open and most everyone in the wheel group then you might as well run as root all the time. 
Sudo is an awesome program, but it needs to have fine tuning done for each system, depending on users.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
i4dnf
Apprentice
Joined: 18 Sep 2005
Posts: 271
Location: Bucharest, Romania
|
| Posted: Sat Dec 20, 2014 11:41 am Post subject: |
|
|
It has nothing to do with su/sudo/sudoers or any of the "classic" tools/configurations.
It's a default polkit policy (put in place for packagekit amongst others) that grants any member of the wheel group administrative privileges when performing administrative tasks via polkit/packagekit, regardless of the sudoers or whatever settings, and this automagically, without the need for extra authentication.
Luckily, Gentoo does the sane thing:
https://bugs.gentoo.org/show_bug.cgi?id=401513
https://bugs.gentoo.org/show_bug.cgi?id=488546
_________________
"The only difference between me and a madman is that I am not MAD" (SALVATOR DALI) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Dec 20, 2014 3:50 pm Post subject: |
|
|
| i4dnf wrote: | It has nothing to do with su/sudo/sudoers or any of the "classic" tools/configurations.
It's a default polkit policy (put in place for packagekit amongst others) that grants any member of the wheel group administrative privileges when performing administrative tasks via polkit/packagekit, regardless of the sudoers or whatever settings, and this automagically, without the need for extra authentication. |
That's insane.
I'm left feeling even more convinced that it's better just to use PAM, and none of this nubkit stuff whatsoever.
| tld wrote: | | Maybe I'm just slow today...everything I read about that supposed issue seems to go by me. I'm not sure if I've been misunderstanding the purpose of the wheel group. |
I think you are as:
| Quote: | | I've always had my own user set up to belong to the wheel group, in order to be able to use su to become root. It of course requires that I know the root password to do so. |
does not require you to be in wheel. If you know the root password, you can su - whenever you want.
Wheel is traditionally for sudo, and can also be used to lockdown directories. How you configure sudo is up to you, as shown in Anon's post; usually people set it up so that wheel can sudo su - same as every other command. In a multi-user environment, as opposed to a personal device, they'd usually have to enter their password (not root's) to do so.
| Quote: | | Is there some inherent risk there I'm not aware of? Is it the case that, for example, that some/all local privilege escalation vulnerabilities only work if the user belongs to wheel? |
Only if you have sudo setup for wheel to run anything without a password. Any sort of ability to run malicious code as the user is already serious; for personal machines, that's effectively the "keys to the kingdom" since they only manage the one user's data, by definition.
So in that context it doesn't really make much odds, in terms of impact. Either way, everything that matters is leaked. (That's why the UNIX model is so much more useful than the Windows kludge.)
sudo for a personal user is more about ensuring they think before they do anything requiring privilege. It's equivalent to a DE asking if you're sure you want to shutdown the machine, before it goes ahead and does it.
Interesting link, thanks. (emphasis added, throughout)
| Darren Shepherd wrote: | | It’s not that Rocket doesn’t have a stand alone daemon it is just that that daemon happens to be systemd, PID 1, which runs as root. So is Docker fundamentally flawed? I can’t imagine how you could say that because Rocket follow a very similar paradigm, it just happens to be built into systemd. The fundamental issue is that both Docker and systemd want to be the daemon to manage containers. |
Man, I'd much prefer separation.
| Chris Swan wrote: | | What's very clear is that systemd isn't needed at all inside a container; an init system isn't required for a single process (or even a handful of processes to support a given service). It also seems like systemd is both overkill for starting Docker, and a mismatch of process control approaches. So perhaps the systemd refuseniks were right — it doesn’t seem to have any proper place in a world of containerized services. |
And this seems to me to be the interesting part in terms of future developments:
| Quote: | | Meanwhile, the field is wide open for new distributions to run in Docker (and for the time being Docker has been hugely successful by letting developers stick with what they know and carry on using their distro of choice). |
Given that systemd just gets in the way, I imagine in a couple of years, all the "kewl kids" will be going on about this radical "new" approach of using all this amazing old, "forgotten" code that simply does what it's told to, and nothing else.
"Look how much quicker it runs, by doing so much less!" ;-) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Dec 20, 2014 4:48 pm Post subject: |
|
|
| steveL wrote: | | Quote: | | I've always had my own user set up to belong to the wheel group, in order to be able to use su to become root. It of course requires that I know the root password to do so. |
[...] does not require you to be in wheel. If you know the root password, you can su - whenever you want. |
steve ... that's not the case, if pam is enabled on sys-apps/shadow (which it is by default) then the following is in effect:
/etc/pam.d/su
| Code: | | auth required pam_wheel.so use_uid |
I believe the handbook states that the user account created should be added to wheel (for this reason).
Anyhow, the real issue here is how permissive access to the system is, with polkit et al, the rational seems to be lessen the strictness for the sake of "the user experience" (whatever that might mean), hence NOTABUG/WONTFIX. The initial "bug" did make it seem that there was something more than "risk", and that essentially was overstating the actual issue.
Its obvious that the stricter the rules in place to maintain privilege separation the greater the barrier to overcome to circumvent those rules, and for my part I would opt for strictness over "the user experience".
best ... khay |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Sat Dec 20, 2014 4:52 pm Post subject: |
|
|
khayyam,
Strictness is and should be "the user experience".
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Dec 20, 2014 4:59 pm Post subject: |
|
|
| NeddySeagoon wrote: | | Strictness is and should be "the user experience". |
Neddy ... I really don't know what the hell is meant by the term, if I wanted a "user experience" I'd take some mind altering drug ... my computer use is, fortunately, experience free ;)
best ... khay |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Sat Dec 20, 2014 5:01 pm Post subject: |
|
|
khayyam,
hehe.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Dec 21, 2014 3:19 pm Post subject: |
|
|
| khayyam wrote: | steve ... that's not the case, if pam is enabled on sys-apps/shadow (which it is by default) then the following is in effect:
/etc/pam.d/su
| Code: | | auth required pam_wheel.so use_uid |
I believe the handbook states that the user account created should be added to wheel (for this reason). |
Ah my bad. I sit corrected ;)
| Quote: | | Anyhow, the real issue here is how permissive access to the system is, with polkit et al, the rationale seems to be lessen the strictness for the sake of "the user experience" (whatever that might mean), hence NOTABUG/WONTFIX. |
It means crap, along the lines of Windows. I really am getting tired of this whole brouhaha, most especially because the whole thing feels like some poor sap's way to reinvent Windows and take on Apple, or some such delusion.
| Quote: | | Its obvious that the stricter the rules in place to maintain privilege separation the greater the barrier to overcome to circumvent those rules, and for my part I would opt for strictness over "the user experience". |
Breaking the user-group-permission model in Unix is simply dumbass. Major-league dumbass, if you've been coding for more than 5 years.
This upstream has no idea what "balance" means; I for one don't want to rely on anything from them, as they haven't even grown-up yet.
I'd only like to deal with people who want to be on a Unix. Not amateurs who run around holding their noses at Unix, in the same way they do shell, and then proceed to break everything they can cajole into their camp.
They really are the total antithesis of everything good in Linux. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
|
| Back to top |
|
|
grot
n00b
Joined: 17 Dec 2014
Posts: 33
|
| Posted: Sun Dec 28, 2014 9:45 pm Post subject: |
|
|
| tld wrote: | | http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdCrashAndMore |
Ah.. good. Yeah when I used journalctl it was pretty terrible. But I'm still pretty new to linux.. I figured if I was better at regexing and piping the output I could get a more readable log. As it was, I guess it did log from the beginning of time, since my Intel i7 with 12 GB ram took forever to scroll through the list - pressing 'End' to get to the bottom took a few minutes, iirc (it felt like forever - but this was a few months ago).
And once I got to the bottom, I couldn't use my vim knowledge to search the log. Just glad I'm not the only one.. |
|
| Back to top |
|
|
GFCCAE6xF
Apprentice
Joined: 06 Aug 2012
Posts: 295
|
| Posted: Sun Dec 28, 2014 10:12 pm Post subject: |
|
|
| grot wrote: | | As it was, I guess it did log from the beginning of time, since my Intel i7 with 12 GB ram took forever to scroll through the list - pressing 'End' to get to the bottom took a few minutes, iirc (it felt like forever - but this was a few months ago). |
Personally it strikes me odd that you'd be surprised that something that does all the logging just throws out all the logs by default when you don't pass any options to tune your output (to me it makes sense, like how I use dmesg) but FWIW:
| Code: | -b --boot[=ID] Show data only from ID or, if unspecified, the current boot
--list-boots Show terse information about recorded boots |
Example output:
| Code: | -7 7e598d3c2f6f4a16934deef34f575d82 Sun 2014-12-21 09:24:49 GMT—Sun 2014-12-21 22:58:30 GMT
-6 4698e8faaf8d4308bee9f1302f233690 Mon 2014-12-22 08:53:18 GMT—Mon 2014-12-22 23:22:56 GMT
-5 16751bcbeae74468b5b60b19dcadf755 Tue 2014-12-23 09:04:08 GMT—Tue 2014-12-23 22:57:57 GMT
-4 b8950cbec04d485d90ac0753ce448933 Wed 2014-12-24 09:13:03 GMT—Wed 2014-12-24 23:53:43 GMT
-3 6b34b00d69ef4026a0da29e35fea4b37 Thu 2014-12-25 09:08:08 GMT—Thu 2014-12-25 23:15:54 GMT
-2 9d3a49d63c2b40bc89f9cca49a3bc215 Fri 2014-12-26 08:51:43 GMT—Fri 2014-12-26 23:46:51 GMT
-1 645aced3c22547e7b182b87e10a2463c Sat 2014-12-27 09:39:35 GMT—Sat 2014-12-27 23:20:53 GMT
0 73222b0b9b6144b0a3439ab3ce679473 Sun 2014-12-28 09:33:17 GMT—Sun 2014-12-28 22:02:57 GMT |
So either 'journalctl -b' for today or journalctl -b 5' for logs of the boot on Tue 2014-12-23 and go even further just getting a services output for that day/session with 'journalctl -b 5 -u crond.service' for example. |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon Dec 29, 2014 9:30 am Post subject: |
|
|
I would actually expect the default to be current boot only. It seems more of a special case to want to look at previous boot logs, and even then you probably rarely want more than one at a time, unless you have no idea what you're looking for.
_________________
|
|
| Back to top |
|
|
GFCCAE6xF
Apprentice
Joined: 06 Aug 2012
Posts: 295
|
| Posted: Mon Dec 29, 2014 10:07 am Post subject: |
|
|
| Perhaps, I've never had an issue with the defaults though and it seems nobody else really has either. The only time I use the bare command is to dump the systems entire log(s) to text file for upload. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 29, 2014 12:44 pm Post subject: |
|
|
| GFCCAE6xF wrote: | | The only time I use the bare command is to dump the systems entire log(s) to text file for upload. |
Which indicates it's a very rare usage-scenario; ergo it shouldn't be the default.
That's just about knowing how people use commands, in their scripts and their terminals; but that requires (or inculcates) an appreciation of Unix, ime. |
|
| Back to top |
|
|
davidm
Guru
Joined: 26 Apr 2009
Posts: 557
Location: US
|
| Posted: Mon Dec 29, 2014 2:03 pm Post subject: |
|
|
I just moved from another binary distro which switched to systemd about two years ago. Honestly it wasn't that bad and usually I had no complaints. However journald was the exception. I found it very cumbersome at times and the idea of a binary system log is something which makes me uneasy. Also I had been noticing more issues with systemd as time went on. The most recent one seemed to be some sort of timing issue which in my case (and many other users) resulted in my btrfs filesystem not being mounted without a workaround modification to a distro specific config file.
My primary concern with systemd at this time is whether or not upstream has the developers needed to properly maintain an ever growing piece of software which seems to take on more tasks every six months or so. If not the bugs will probably get out of hand as time goes on.
For now I am happy with my Gentoo OpenRC install. Everything is now more stable than ever and I feel less annoyed even though it took some study to get used to OpenRC once again. Perhaps in a year or two I might reconsider systemd should my concerns about maintaining it be unfounded.
Last edited by davidm on Mon Dec 29, 2014 3:56 pm; edited 1 time in total |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Mon Dec 29, 2014 2:12 pm Post subject: |
|
|
| steveL wrote: | | GFCCAE6xF wrote: | | The only time I use the bare command is to dump the systems entire log(s) to text file for upload. |
Which indicates it's a very rare usage-scenario; ergo it shouldn't be the default.
That's just about knowing how people use commands, in their scripts and their terminals; but that requires (or inculcates) an appreciation of Unix, ime. |
Of course understanding that would have meant simply sticking with text log files in the first place  . |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 30, 2014 12:22 am Post subject: |
|
|
| steveL wrote: | | That's just about knowing how people use commands, in their scripts and their terminals; but that requires (or inculcates) an appreciation of Unix, ime. |
| tld wrote: | | Of course understanding that would have meant simply sticking with text log files in the first place ;) |
Hehe that is very true.
Seems like every generation has to relearn the lessons; what I love is stepping through things and then realising that, in some other supposedly unconnected corner, I've come across another way in which some principle of the methodology is useful. That really is the factor that tells me things are well-designed: the decisions help in more than one way. eg text interfaces are much more portable, which means you don't have to worry about things like endianess, wordsize and the rest, as well as being able to tweak things as a human which massively helps debugging and maintenance.
Personally I have a suspicion the initial impetus for text-based protocols was floating-point, which has always been a bugbear (IEEE standards notwithstanding.) Given that we're networking heterogeneous machines (or it's not a network, so much as a cluster) taking the "easy" route of textual protocols has deeper implications than just portability.
"Easy" is in quotes as it's always been considered more work for the programmer to serialise, or at least it was when I was coming up; people don't realise how nice C is compared to what came before (or often don't realise how useful it really is, and ignore the basics in favour of some more "convenient" language that really isn't when you get into it at a deep level.)
Weird to see binary protocols being presented as somehow sexy and elite; to my mind they're essentially lazy, in a bad way. "The 'developer' couldn't be bothered," is the impression I get, unless we're talking truly local IPC, ie pipes or shared memory; not generic services, since you will end up needing to debug those across codebases, and human time is much more expensive (or less effective;) than CPU. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Thu Jan 01, 2015 4:32 pm Post subject: |
|
|
Some information and statistics on systemd developers: Who wrote systemd?
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
grot
n00b
Joined: 17 Dec 2014
Posts: 33
|
| Posted: Fri Jan 02, 2015 8:40 pm Post subject: |
|
|
| GFCCAE6xF wrote: | | grot wrote: | | As it was, I guess it did log from the beginning of time, since my Intel i7 with 12 GB ram took forever to scroll through the list - pressing 'End' to get to the bottom took a few minutes, iirc (it felt like forever - but this was a few months ago). |
Personally it strikes me odd that you'd be surprised that something that does all the logging just throws out all the logs by default when you don't pass any options to tune your output (to me it makes sense, like how I use dmesg) but FWIW: |
That's useful advice. As it turned out, the error being reported by systemd was a fluke, so I didn't have to / get to spend too much bonding time with the tool.
Just as a point of interest I just went to the bottom of the log my arch partition, and it snapped to the bottom in ~5 seconds. Although this log is far, far shorter (this one is about 300,000 lines) than the log I was referring to, when I had CentOS7 installed, which barely worked until I installed Gnome 3 (ie, lots of things running all the time). On my arch partition I've opened a few applications and my highest pid is ~1540, whereas CentOS would get to pid over 20000 over the course of a few hours, which I haven't reached on arch over the course of a few days. Finally, I've heard CentOS7 runs an older version of systemd, so perhaps it runs a less efficient version of journald?
I feel bad since this post is mostly ignorant speculation, but I want to be fair here in that journald is performant is this case. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 03, 2015 1:14 pm Post subject: |
|
|
| It's not like dmesg though, is it? dmesg is a limited ring-buffer, so on its own dmesg is already giving you a limited snapshot. |
|
| Back to top |
|
|
GFCCAE6xF
Apprentice
Joined: 06 Aug 2012
Posts: 295
|
| Posted: Sat Jan 03, 2015 2:18 pm Post subject: |
|
|
| steveL wrote: | | It's not like dmesg though, is it? dmesg is a limited ring-buffer, so on its own dmesg is already giving you a limited snapshot. |
It was just intended as a basic example of something where typing the 'raw' command would give you a load of spam as output.
All our work images contain a dmesg alias to alter the behaviour (only adds --human these days) but even then it's rare to use dmesg 'rawly' since 95%+ of the time we at are at least specifying facility and/or log level with it. Likewise with journal I usually at least specify if I want system or user logs and then other specifics and maybe even | grep on the end too.
I do think -b would be a good sensible default, I would like outputting --help instead though  Anyway, it seems to me that not many people care about that default. Tallying up journal commands from my bash history tells me I've typed 'journalctl /usr/bin/su' more times (7-2) than I have 'journalctl -b'. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jan 03, 2015 2:45 pm Post subject: |
|
|
Text files that can be used with all the countless exiting tools...period. I can't believe so many out there seem to be missing the simple elegance of that approach...especially for something as utilitarian as logs.
Everything I read about journalctl reminds me of heading out to visit my neighbor across the street, only doing so by starting out in the other direction... |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sat Jan 03, 2015 8:31 pm Post subject: |
|
|
I have to agree with tld, I find it's better with plain text logs. Quite frequently, I have on my next work where my logs have a copy forward to another machine (which usualy ends up being again forwarded (copies) to a 3rd+ machine) in a daisy chain fashion. I find this works quite well for me, in that if one of my machines get hacked, sure, the hacker may compromise that machine. But when you have a different copy on 8 different machines (each keeping a log set for each machine and their own local log), make it unlikely they can find all of them. For a binary file, it's easy to corrupt a binary file making it effectively useless on figuring out what all got tampered. All they have to do (assuming the said hacker knows where the file is located), is do a simple echo "some file" >> binary_log. Now the entire binary log file is trashed. Sure you'll know it's corrupted, but beyond that you are now S.O.L.
Another thing I usually setup on my machines, is I specifically have my logs split to multiple files to help narrowing down issues (while having a common over-view log for quick checks, while the split logs have the details/debugging information as necessary). |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Jan 03, 2015 9:06 pm Post subject: |
|
|
| ct85711 wrote: | | Sure you'll know it's corrupted, but beyond that you are now S.O.L. |
It's worst than that, you cannot even assume a corrupt log is because of an attacker as systemd have a bug that corrupt it and is resolve "not a bug". (i don't have the link but it must be somewhere in the thread)
For text log, if an attacker clear it, you are the same point, except you know "someone" as intentionally done it. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sun Jan 04, 2015 6:28 pm Post subject: |
|
|
On a semi-related issue, I have to confess that I've really not been following much about Wayland, mostly because it didn't seem to be something I needed or was interested in.
As I start reading about that the thing that jumped out at me was the lack of network transparency...not so much the fact that they don't support it, but the annoying manner in which they talk around the issue just as they do with all systemd issues. If they're not trying to cloud the issue by "debunking" it with deceiving terminology that pretends they have it when they don't, they seem to be blowing off the whole thing with "nobody uses that". F*** that...I use it...and all the time at that...primarily on my headless MythTV backend.
I am so sick of those ass-hats telling everyone what they "need" and "want". At a point it almost starts sounding like "If you can't do that in Windows, why do you want it?". |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
