| View previous topic :: View next topic |
| Author |
Message |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
 Posted: Thu Jun 02, 2016 11:27 pm Post subject: |
 |
|
| depontius wrote: | | Heck, on my machine I'm on any group I need to be. But looking at my /etc/group, if I had some sort of console restriction capability I'd only be in wheel, users, and family - and my kids certainly wouldn't get wheel. (Maybe now they would, since they're adults, but not as kids.) |
depontius ... but what has this to do with nohup, as I said in my initial reply "these are separate functions to duration, and job control". Looking back over what you'd written I can only acertain that "nohup really is broken" because: groups.
| depontius wrote: | | As for no remote access, I don't know... 40 years ago our school had a fledgling network and I'm under the impression that we had remote access, even if it might have been a KSR-33. Co-workers in years since then, though I haven't asked about it in the past decade, seem to have had remote access. [...] |
Not to graphical workstations, and definitely not from outside the local network ... sure, 40 years ago you could have setup a wardialer and found any number of schools, businesses, government agencies, providing some sort of remote access, but such things are limited to webservers, and the like, these days.
| depontius wrote: | | [...] But even without remote access, go in first thing in the morning, nohup your malicious monitor job, come back in the evening and see what it has fished up for you. |
The assumtion being that unix ACL's are not equiped to deal with users abusing the system. So this doesn't remain purely theoretical can you provide an example of such a "malicious monitor", and if not, why?
best ... khay |
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri Jun 03, 2016 12:18 am Post subject: |
|
|
| khayyam wrote: | | Looking back over what you'd written I can only acertain that "nohup really is broken" because: groups. |
My contention is that nohup as currently implemented allows any enhanced privileges that were granted to you as the console user to survive past your console residence. At the moment, yes that means groups. I don't know what more *kit or systemd do, but I suspect they're even more privilege-granting happy than anything I would consider. (packageKit, anyone?)
I also suspect that nohup could be rewritten to be fully safe, and make sure that all enhanced console privileges are removed prior to the nohup'ed job starting. It might need a little extra support (from pam?) in order to be a fully drop-in replacement for the current nohup, but I think it could be done.
| khayyam wrote: | | The assumtion being that unix ACL's are not equiped to deal with users abusing the system. So this doesn't remain purely theoretical can you provide an example of such a "malicious monitor", and if not, why? |
The one example I might give is a college sophomoric stunt - the nohup'ed job would open the microphone and video camera and just spy on the console. I've never really done low-level programming on Linux, so this is the simplest I can suggest. It's only gathering mostly boring stuff, and the best it's likely to get is a conversation that was meant to be private, but it's an invasion of privacy. Opening those devices grabs exclusive access, so that means if someone else comes along and wants to run a video call, it will fail, but I don't know how high a probability that is. Nor do I know if there are tricks to avoid that, or make it look like an intermittant fail.
Another trick, and I'm not sure how practical this is, would be to remount a USB stick after it's been umounted, snoop quickly, then dismount. That would be tricky, because at best you'd get a few seconds before the USB stick was pulled, an observant user might see the light (if it has one) blink extra, and I'm not sure if non-root can recover when a USB device is pulled before being umounted. (Never tried it, I try to be careful.)
With rootless X there might be more possiblities, though I'm not sure how easy it is to get shared access to a resource. Even in the old DISP=SHR days (Yes, I used to write JES2 JCL.) I believe you couldn't share just anything.
The examples I've given are pretty trivial, may not work, etc. But they're also "classic API' stuff. NOW insert one of those incredibly secure pieces of software like *kit or systemd and ask what might be gotten away with - with console-elevated access. I have enough cracker mentality to try to secure my own stuff, but the only time I've ever really come close to cracking, myself, is to explore a new system I've just been granted access to. Even then it's more like exploring a new building than cracking.
There's a certain defensiveness in old-Unix school when systemd comes up, to say everything's perfectly fine. I don't believe that, I believe everything is good and adequate, but not necessarily perfect. By the same token, I think that systemd has come up with a bunch of broken non-answers.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jun 03, 2016 5:21 am Post subject: |
|
|
| depontius wrote: | | khayyam wrote: | | Looking back over what you'd written I can only acertain that "nohup really is broken" because: groups. |
My contention is that nohup as currently implemented allows any enhanced privileges that were granted to you as the console user to survive past your console residence. At the moment, yes that means groups. I don't know what more *kit or systemd do, but I suspect they're even more privilege-granting happy than anything I would consider. (packageKit, anyone?) |
depontius ... this has nothing to do with nohup, what you are promoting is the idea that such things should change on the fly, and at the same time conflating this with "systemd people are right" WRT nohup, when their reasoning had nothing to do with access but the fact that (gnome/dbus) sessions don't do the right thing.
So what is deciding what access I should gain in one instance but not another? Are you planning on mixing policy with mechanism? In the scenario you described (ie a university) it is trivial to kill all running processes on logout, that is something an administrator can do under the current mechanism, so we can regard this as SOLVED. What if, say, I ssh to some machine and run ffmpeg, should I get access to the video card and so utilise cuda HW decoder? By the policy mechanism implied by your "console login privileges" sive "ordinary privileges" no, because the video card is the domain of "console". What if this is a job that may take days to complete, can I nohup, or will I suddenly find the job can no longer access the card? Or, say, should I need to burn a CD, I can't insert a disk into a headless machine, ssh, burn and eject? You see where I'm going with this, what is deciding what access I get, and under what circumstances? So, while it may seem that "console login privileges" are a problem, the solution would very likely be worse ...
| depontius wrote: | | I also suspect that nohup could be rewritten to be fully safe, and make sure that all enhanced console privileges are removed prior to the nohup'ed job starting. It might need a little extra support (from pam?) in order to be a fully drop-in replacement for the current nohup, but I think it could be done. |
It is "fully safe", but you are looking at it as something which needs to change so that a policy-mechanism is in place. If I don't want $user to leave jobs running I can already deal with them, for most cases I do, and that what the current policy does. As Tony0945 stated, "there is no way to protect against a malicious trusted user. Unless you make the PC unusable for ordinary use", and in that regard the current mechanisms available are perfectly fine.
| depontius wrote: | | khayyam wrote: | | The assumption being that unix ACL's are not equiped to deal with users abusing the system. So this doesn't remain purely theoretical can you provide an example of such a "malicious monitor", and if not, why? |
The one example I might give is a college sophomoric stunt [...] |
These are not examples, these are hypotheticals.
| depontius wrote: | | There's a certain defensiveness in old-Unix school when systemd comes up, to say everything's perfectly fine. I don't believe that, I believe everything is good and adequate, but not necessarily perfect. By the same token, I think that systemd has come up with a bunch of broken non-answers. |
Yes, because more often than not those promoting systemd, etc, have only a scant knowledge of unix, and think that the fact that it is "old" somehow means that its not on par with the "new" (or some other slight of hand). Also, I would expect any technical appraisal of technology be driven by reasoning, logic, prior art, etc, and not by evasion, misdirection, doublespeak, etc ... yes, I really *hate* that.
best ... khay |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Fri Jun 03, 2016 2:00 pm Post subject: |
|
|
| Tony0945 wrote: | | There is no way to protect against a malicious trusted user. Unless you make the PC unusable for ordinary use. |
Exactly. I'm frankly stunned that this debate is going on here. If the privileges for an existing user change for some reason, it's totally on the admin to see if they have anything running. Just as khay has been saying, user permissions and duration of processes have nothing to do with each other. Attempting to deal with that automatically by killing processes on logout will be broken for some use cases, which is why things have never worked that way. As always, the simple approach here is, and has been, the best.
Let's also stop pretending they're doing this for security reasons in the first place. They're doing it because the Gnome/dbus folks are to lazy or clueless to fix their own stuff. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Jun 03, 2016 5:20 pm Post subject: |
|
|
| tld wrote: | | If there's some supposed security risk of allowing things like nohup, because an admin might remove permissions that the user had when they started a process, then I say it's on the admin to actually look for any running processes. |
What you describe here is what systemd does: When the user logs out, polkit's gonna remove his provilieges. So it's to the admin (systemd) to kill any running processes (which was started with previous privileges). An insane strong workaround which makes no sense on many systems, but certainly one which closes this type of security hole.
The real problem, of course, is the insanity of polkit to provide privileges dynamically: The very reason why polkit exists is plain wrong! |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Jun 03, 2016 9:10 pm Post subject: |
|
|
| mv wrote: | | The real problem, of course, is the insanity of polkit to provide privileges dynamically: The very reason why polkit exists is plain wrong! |
Heartily concur! |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 801
|
| Posted: Sat Aug 20, 2016 4:37 pm Post subject: |
|
|
Another system falls.. And we fall back. |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Sun Aug 21, 2016 2:13 pm Post subject: |
|
|
Love the justification for this, typical Poettering 'we didn't invent it, so we're rewriting it because we know better than you':
| Lennart Poeterring wrote: | | In many ways, systemd-mount is similar to the lower-level mount ( 8 ) command, however instead of executing the mount operation directly and immediately, systemd-mount schedules it through the service manager job queue, so that it may pull in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may make use of the auto-mounting logic. |
I wonder when he's going to finally make the announcement, that what SystemD really is is its own OS. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sun Aug 21, 2016 2:57 pm Post subject: |
|
|
| Shamus397 wrote: | | I wonder when he's going to finally make the announcement, that what SystemD really is is its own OS. |
+1000. The whole thing has been going on for years now but never ceases to amaze me. They're no longer trying to even pretend it's an init system. I'd have to think that all/most of the distros that chose to cave to this BS must be starting to do a huge WTF. Are they just all going to continue riding the train from Linux to PoeterringOS? I just have to believe there's more sanity out there than that. Maybe there's just more of the "as long as it seems to work" mentality out there than I realize.
...and tell me again why mounting file systems requires asynchronous scheduling??...just to make sure that when you "mount" something, you don't actually know if it's really "mounted" or not? No words. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Aug 21, 2016 3:27 pm Post subject: |
|
|
| Shamus397 wrote: | Love the justification for this, typical Poettering 'we didn't invent it, so we're rewriting it because we know better than you':
| Lennart Poeterring wrote: | | In many ways, systemd-mount is similar to the lower-level mount ( 8 ) command, however instead of executing the mount operation directly and immediately, systemd-mount schedules it through the service manager job queue, so that it may pull in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may make use of the auto-mounting logic. |
I wonder when he's going to finally make the announcement, that what SystemD really is is its own OS. |
That was made long ago, rough quote: "SystemD writes to Linux, and other people write to SystemD." That's a vision that says that SystemD is a layer completely surrounding the kernel, and that is consistent with their actions to date. So if you want to know what's next, take a look at /sbin and /usr/sbin, and finish putting "systemd-" in front of everything there.
The other, long-term play is the container. SystemD is poising itself to be the OS to the container. Imagine a longer-term future of "containerized applications" where SystemD solves Linux's "dll hell" by having containers be self-sufficient. In other words, /lib and /usr/lib empty down to what's needed to support booting the system, SystemD, and Wayland.
What "dll hell" problem does Linux have, you might ask? Why, none at all. But that hasn't stopped several years now of L.P. assuming that Linux has Windows problems and wedging Windows solutions into Linux. By the way, once applications are containerized, sometimes they will have to talk to each other - enter systemd-activeX.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 801
|
| Posted: Sun Aug 21, 2016 4:30 pm Post subject: |
|
|
| Shamus397 wrote: | Love the justification for this, typical Poettering 'we didn't invent it, so we're rewriting it because we know better than you':
| Lennart Poeterring wrote: | | In many ways, systemd-mount is similar to the lower-level mount ( 8 ) command, however instead of executing the mount operation directly and immediately, systemd-mount schedules it through the service manager job queue, so that it may pull in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may make use of the auto-mounting logic. |
I wonder when he's going to finally make the announcement, that what SystemD really is is its own OS. |
The phoronix forums, usually a system-d lover haven. Seems to have changed it's stance a little. More and more are viewing this as a 'bridge too far' move with less people shouting them down as trolls or haters of progress. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Aug 21, 2016 4:52 pm Post subject: |
|
|
| truekaiser wrote: | | More and more are viewing this as a 'bridge too far' move with less people shouting them down as trolls or haters of progress. |
"Bridge too far?" When you have the policy controls of SystemD in place, you don't NEED su or even root login. After all, misappropriation of admin authority is one of the security problems of Windows. Time to apply a Windows solution to Linux, and do away with root. Is that bridge far enough for you?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Aug 21, 2016 4:55 pm Post subject: |
|
|
| depontius wrote: | | truekaiser wrote: | | More and more are viewing this as a 'bridge too far' move with less people shouting them down as trolls or haters of progress. |
"Bridge too far?" When you have the policy controls of SystemD in place, you don't NEED su or even root login. After all, misappropriation of admin authority is one of the security problems of Windows. Time to apply a Windows solution to Linux, and do away with root. Is that bridge far enough for you? |
no, need telemetry data going back to redhat
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sun Aug 21, 2016 6:42 pm Post subject: |
|
|
| Quote: | | no, need telemetry data going back to redhat |
Why stop at only telemetry data? Might as well throw the entire bucket in, and do a complete root access open to the web. It's not like we are caring about security or privacy anymore. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 801
|
| Posted: Sun Aug 21, 2016 6:49 pm Post subject: |
|
|
| depontius wrote: | | truekaiser wrote: | | More and more are viewing this as a 'bridge too far' move with less people shouting them down as trolls or haters of progress. |
"Bridge too far?" When you have the policy controls of SystemD in place, you don't NEED su or even root login. After all, misappropriation of admin authority is one of the security problems of Windows. Time to apply a Windows solution to Linux, and do away with root. Is that bridge far enough for you? |
A bridge too far was a while ago for me. I was only pointing out that the phoronix forums, which has been for a long while a system-D haven. Are starting to question what is happening. :/
Don't start attacking me please, even if the political ideology of this forum blinds a lot of people from the root of the entire problem.. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Aug 21, 2016 7:11 pm Post subject: |
|
|
Are you sure phoronix is questioning it more. I read the 150+ thread and there is the usual supporters belittling any objection
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 801
|
| Posted: Sun Aug 21, 2016 7:26 pm Post subject: |
|
|
| Naib wrote: | | Are you sure phoronix is questioning it more. I read the 150+ thread and there is the usual supporters belittling any objection |
There were less supporters and more questioning it when i read the article's comments yesterday. To me it's an improvement because it's normally complete support.. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Aug 22, 2016 6:48 am Post subject: |
|
|
| Naib wrote: | | Now SystemD replaces mount |
Now? This had happened long ago when systemd was canceling "mount -a" and had replaced it by its mount units which are autogenerated at boot time from /etc/fstab; probably since the beginning of systemd (or very close to). If I understand the posting correctly, systemd-mount is just a way to start these mount units (and perhaps an alternative way to create them) - of course, there should be a way to do this individually, similarly as service files can be started and stopped individually as well.
So this new(?) command is not dramatic - the real tragedy had happened much longer before... |
|
| Back to top |
|
|
Maitreya
Guru
Joined: 11 Jan 2006
Posts: 441
|
|
| Back to top |
|
|
Treborius
Guru
Joined: 18 Oct 2005
Posts: 585
Location: Berlin
|
| Posted: Mon Aug 22, 2016 12:00 pm Post subject: |
|
|
ok, i was shocked as i read that in the bug-report :
| Quote: |
> I am still not 100% sure if it is considered ready for prime time
As far as I can tell, Lennart's proposed patch on fd.o #95263 would reintroduce CVE-2014-3637 (fd.o #80559), a denial of service security vulnerability.
|
what the hell are these guys coding there, a video game or an init-system?
my conclusion ==>
second to last resort : Gentoo
last resort : bsd
_________________
Systems running gentoo :
Desktop, Laptop, ZOTAC AD-10 media-center, odroid-xu4 server / wLan-router |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Mon Aug 22, 2016 1:07 pm Post subject: |
|
|
| Treborius wrote: |
what the hell are these guys coding there, a video game or an init-system?
my conclusion ==>
second to last resort : Gentoo
last resort : bsd
|
It's consistent with the idea that you have to reboot your system every 49.2 days. Remember, that happened to Windows a few years back.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mrsteven
Veteran
Joined: 04 Jul 2003
Posts: 1938
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Aug 22, 2016 3:57 pm Post subject: |
|
|
| depontius wrote: | | Pages and pages of snarky comments, interspersed with a few, "If you really understood systemd..." comments. |
I love this one: | Quote: | | Systemd would be a a great OS... all it needs is a decent init system. |
|
|
| 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
