stevelitt | Alright, let me try ceres again... | 00:52 |
---|---|---|
gnarface | stevelitt: stuff is gonna be different enough that old configs in your home directory can cause userspace damage that may look just like a broken system until you purge the old configs (VLC is a frequent offender in this regard, but hardly the only one) | 01:04 |
gnarface | in general it might be safer to upgrade from a headless, minimal ascii install than something you've already worked to configure the user environment for | 01:05 |
gnarface | the version of Xorg in there isn't even compatible with the same range of NVidia drivers, i don't think | 01:05 |
saptech | when dragging a url to folder im getting error 'Failed to create a link for the URL' | 01:35 |
saptech | any idea what's going on with it? | 01:36 |
Xenguy | Maybe it's an existing bug, or one that still needs to be reported? | 01:38 |
saptech | ok | 01:40 |
saptech | my first time noticing this happening | 01:40 |
furrymcgee | how can devuan used as freeipa-server the package is missing in the repository | 10:12 |
negev | hai | 10:39 |
negev | openssl 1.1.1 seems to cause issues with some stuff | 10:39 |
negev | eg: https://gist.github.com/m4rkw/84eb64d60a6ec5b9379cb834a7394e99 | 10:39 |
negev | i can't find libssl_conf.so anywhere on the system with either 1.1.0f or 1.1.1 | 10:40 |
negev | it's not referenced in the openssl.cnf or in ldd output for phantomjs | 10:40 |
* man_in_shack flails | 10:45 | |
man_in_shack | got me my bluray discs playing over iscsi | 10:45 |
man_in_shack | not dvds because fuck css encryption shit | 10:45 |
rrq | ngev: how about https://github.com/drwetter/testssl.sh/issues/1117#issuecomment-418508290 | 10:45 |
negev | rrq: i saw that but i don't really understand it | 10:47 |
rrq | suggests that you set OPENSSL_CONF to pinpoint your openssl.cnf | 10:48 |
negev | but i only have one openssl.cnf anyway | 10:49 |
negev | how would that help? | 10:49 |
gnarface | man_in_shack: the libdvdcss2 from videolan.org works for general purpose | 10:50 |
negev | ah, using the openssl.cnf from manually compiled openssl 1.1.1 seems to work | 10:50 |
man_in_shack | gnarface: yah but tgt seems to have trouble reading the encrypted packets and passing that over to libdvdcss :) | 10:51 |
gnarface | you sure you didn't just forget libdvdnav4? | 10:51 |
man_in_shack | yes | 10:51 |
man_in_shack | let me doublecheck | 10:52 |
man_in_shack | yah it's installed | 10:52 |
man_in_shack | does look like it's tgt's fault | 10:53 |
man_in_shack | (: | 10:53 |
man_in_shack | so what i doing is running a remote X server with vlc in | 10:54 |
man_in_shack | cos the 10 year old core2 duo can handle that | 10:54 |
plasma41 | Good Morning | 17:01 |
_abc_ | Hi. Is the patched xorg alredy in the devuan updates package stream for ascii? I find it confusing that I have to ask about this knowing "upstream" is always official debian... | 17:07 |
plasma41 | What patch is this? | 17:08 |
_abc_ | #2: I lol'd at the thought Poettering may end up wearing a suit to work. IBM bought Red Hat. I am curious how these two cultures will clash. They are like fire and water. | 17:08 |
_abc_ | plasma41: the security patch for the bug which permits overwriting any system file by a user starting xorg with crafted log file list. | 17:08 |
plasma41 | I hadn't heard about that bug | 17:09 |
_abc_ | https://www.bleepingcomputer.com/news/security/trivial-bug-in-xorg-gives-root-permission-on-linux-and-bsd-systems/ well now you have | 17:09 |
_abc_ | devuan ascii has xorg 1.19.2 and is vulnerable. | 17:11 |
_abc_ | https://www.youtube.com/watch?v=qPlVNjUq_hU interview with Poettering, in German. In the 1st 2 minutes he says systemd is hopefully better since "we tried to get the best parts of the Apple OS init system, and from Solaris's sms". Tried. And still trying. Right. | 17:16 |
_abc_ | I find it super amusing he's now an IBM employee. | 17:16 |
nemo | I thought that bug was embargoed to allow distros to fix | 17:16 |
nemo | surely debian would have done so? | 17:16 |
_abc_ | I think IBM made one project on someone's "knee" once in it's history, with no ties attached and no control over developers. That was the IBM PC project, as I read it. | 17:16 |
_abc_ | nemo: Do you auto update? I don't. | 17:17 |
nemo | $ ls -l /usr/bin/Xorg | 17:17 |
nemo | -rwxr-xr-x 1 root root 274 Oct 14 2017 /usr/bin/Xorg | 17:17 |
nemo | not suid | 17:17 |
nemo | no idea when it stopped being suid | 17:17 |
nemo | maybe never was | 17:17 |
nemo | _abc_: that's what pissed off the BSD folks since they would have dropped that on theirs had they been alerted | 17:18 |
nemo | _abc_: I imagine for most setups running X without suid is a pretty sensible default. so could have been that way for years | 17:18 |
nemo | actually surprised BSD didn't do that | 17:18 |
nemo | _abc_: https://wiki.gentoo.org/index.php?title=Non_root_Xorg&action=history gentoo's page on this dates back to 2014 | 17:19 |
nemo | _abc_: https://www.phoronix.com/scan.php?page=news_item&px=Debian-Non-Root-X | 17:24 |
nemo | 2015 | 17:24 |
_abc_ | The hole is indeed 2 years old. | 17:27 |
_abc_ | Xorg stopped being suid a long time ago but that does not change things. Try ps -auxwf and look for xorg in the tree. | 17:28 |
_abc_ | On my ascii Xorg is executed by slim and runs as root | 17:28 |
_abc_ | The config files which are partly user specifiable at start time can be modified by the user to make Xorg log to key system files instead, and clobber them. | 17:29 |
nemo | _abc_: ah you're right. crud. | 17:30 |
nemo | _abc_: well I know about the age of the hole and the risk, I just assumed suid :/ | 17:30 |
nemo | didn't think they'd be running a wrapper helper | 17:30 |
_abc_ | Again: non suid Xorg running since 1.17, bug since 1.19 | 17:30 |
_abc_ | It does not matter what they run while the philosophy of the Xorg is to accept config files added by the executing user anywa. | 17:31 |
_abc_ | y as root. | 17:31 |
nemo | um... what's that "Again" about? how are we contradicting | 17:31 |
nemo | you're right about the root thing. it's just surprising since I thought they were trying to get rid of that, as the phoronix article notes | 17:32 |
_abc_ | The setsuid Xorg binary is no longer setsuid since 1.17. The current bug appeared in 1.19 | 17:33 |
_abc_ | Back to IBM bearhugging RH: https://www.theregister.co.uk/2017/08/23/red_hat_microsoft_container_alliance/ | 17:33 |
nemo | yeah, I'm just confused as to why they would remove setuid and still run Xorg as root | 17:33 |
nemo | that seems to totally defeat purpose | 17:33 |
_abc_ | IBM ceo said that the new merge will "change the way container runners work". I am curious. Usually IBM does not lob tasty morsels towards M$. | 17:34 |
_abc_ | nemo: it is executed by the login manager which acts as a wrapper. | 17:34 |
_abc_ | slim in my case | 17:34 |
nemo | aaaanyway | 17:35 |
nemo | _abc_: yeah. that is obv. I don't get the WHY 😝 | 17:35 |
nemo | aaaaaaaanyway | 17:35 |
nemo | https://launchpad.net/debian/+source/xorg-server/+changelog | 17:35 |
nemo | clearly debian does NOT have the CVE fixed in 1.19 ☹ | 17:35 |
nemo | there's no evidence of it anywhere in the changelog apart from 1.20 | 17:36 |
nemo | at least it's "just" local ☹ | 17:36 |
nemo | not that that helps multiuser setups at all | 17:36 |
_abc_ | chnagelog for 1.19.2-6 seems to imply a lot of OTHER holes were also present and sanitized with that release. | 17:37 |
_abc_ | And I am not on that, but I am willing to bet that that is the upgrade path for 1.19.2 on ascii | 17:37 |
nemo | _abc_: hmmm | 17:37 |
nemo | _abc_: do you think since it was a security bug the CVE was not mentioned in the changelog? | 17:38 |
nemo | it was embargoed and all | 17:38 |
nemo | so 1.20 only shows it due to being post-announce.. | 17:38 |
muep | so is Xorg installed with suid in Debian? my impression is that it is without suid | 17:38 |
nemo | muep: it's without suid yes. the confusing part (to me) is why the login manager would still run it as root, instead of user privs | 17:39 |
nemo | or a restricted account for the actual login manager itself | 17:39 |
nemo | _abc_: I guess the only way to know for sure would be for me to debsrc my existing .deb and actually check the affected area | 17:39 |
_abc_ | dpkg -l xserver-xorg -> 1:7.7+19 ?! | 17:39 |
nemo | ?? | 17:39 |
muep | nemo: AFAIK it is just the traditional way to have the login manager running as root | 17:40 |
muep | it will still launch the desktop session processes with an unprivileged account when someone logs in | 17:40 |
_abc_ | muep: Xorg is not suid but it's manager calls it up as root | 17:40 |
nemo | muep: does that actually insulate against this bug? seems unlikely | 17:41 |
nemo | muep: and why trust X that much - why not just drop all privs | 17:41 |
* nemo shrugs | 17:41 | |
muep | nemo: do you udnerstand how the bug works? | 17:41 |
_abc_ | How does one list the actual installed version of the deb not of the contents? | 17:41 |
muep | dpkg -l somepackage | 17:42 |
nemo | muep: so... I read the announcements, but my knowledge of X itself? nowhere near good enough to know how one might exploit it | 17:42 |
nemo | muep: besides the mentioned commandline | 17:42 |
_abc_ | I just did that. But the actual version of Xorg is sussed out by: sudo Xorg -version | 17:42 |
_abc_ | And THAT is 1.19.2 here | 17:42 |
nemo | muep: X is a big tangled mess to me, and would not surprise me at all if that module loading can be done in some API or X protocol thingy and not just commandline | 17:43 |
_abc_ | Specifically: xorg-server 2:1.19.2-1+deb9u2 | 17:43 |
_abc_ | Why did debian have to add new and unconnected package versioning and hide the actual program's versions? | 17:43 |
yap | salve | 17:44 |
muep | nemo: my impression is that the problem is not because X runs as root. as usual with SUID binaries, the problem is the automatic transition from a non-privileged user to a privileged one, combined with the privileged process doing wrong things when the unprivileged caller provides suitable input | 17:44 |
_abc_ | Do you see how *useful* being able to see the actual program version is now? Looking in aptitude or whatever? | 17:44 |
muep | _abc_: that is 1.19 isn't it? | 17:44 |
nemo | yeah. I don't get what he's talking about... 1.19.2-1+deb9u2 | 17:45 |
_abc_ | muep: which "that". The deb package isn't. It's 1:7.7+19 | 17:45 |
nemo | where typically everything past the dash is debian's stuff | 17:45 |
nemo | _abc_: xserver-xorg-core | 17:45 |
nemo | _abc_: the other one is https://www.x.org/wiki/Releases/7.7/ presumably | 17:46 |
_abc_ | At least you are right in that xserver-xorg does not provide Xorg, -core does. | 17:46 |
nemo | _abc_: xorg folks have their own separate server versioning so makes sense debian would use it too | 17:47 |
muep | _abc_: ah, I did not notice that other one. but yep it seems that X.org has some version for the X server and other version numbers for other things they release alongside it | 17:47 |
nemo | mhm | 17:47 |
nemo | muep: mentioned right in that 7.7 release announce actually, 1.12 server release | 17:47 |
_abc_ | muep: yes, so I was barking up the wrong tree, sort of. | 17:47 |
muep | but really I do not see how you would use the setup with login manager running as root, to exploit this bug | 17:48 |
nemo | aaanyway. fetching deb-src of xserver-xorg-core 1.19.2-1+deb9u2 would end all the speculation ☺ | 17:48 |
nemo | muep: I have nooooo idea, but I'm also don't know a ton about just what X exposes where - my familiarity with its internals is low enough that I'd rather be patched or the server dropping privs ☺ | 17:49 |
muep | at least the trivial case of an unprivileged user being able to launch the privileged X server process with arbitrary cmdline args is not available | 17:49 |
nemo | muep: but yes, if it is ONLY commandline then no suid avoids | 17:49 |
nemo | yep | 17:49 |
muep | nemo: you do not need to understand X.org internals at all to understand this bug | 17:49 |
nemo | muep: I understand the bug just fine. what I don't know is if that's the only pathway | 17:49 |
nemo | that was my only point | 17:49 |
nemo | or let's say, I read the diff and the explanation of how it was fail. | 17:50 |
muep | of course there may be some other bugs in X.org which make it a good idea to run it as non-root | 17:50 |
nemo | not gonna go further than that on the understanding part ☺ | 17:50 |
nemo | muep: well given how many times the word CVE shows up in https://launchpad.net/debian/+source/xorg-server/+changelog … ☺ | 17:51 |
muep | but this currently famous one does not look like it would be an issue unless suid is used | 17:51 |
nemo | or in https://launchpad.net/debian/+source/xorg-server/2:1.19.2-1+deb9u2 at least | 17:52 |
_abc_ | You can't really run any xserver as non root, it's a misnomer. Parts of it run as non root, but the core always runs as root, it interfaces with the hardware directly. | 17:52 |
_abc_ | I wonder if upgrading Xorg will break anything directly and immediately. | 17:52 |
muep | on my desktop it runs as muep | 17:53 |
nemo | _abc_: well... the gentoo guide for running X as root solves that, it seems, by adding trusted gui users to a group with the hardware access | 17:53 |
heaven | (^:^) | 17:53 |
nemo | https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_changes_to_system | 17:53 |
_abc_ | Yes nemo but eventually it runs as root... essentially it's peeking and poking kernel memory at a level at which it can do anything once penetrated. | 17:54 |
muep | I don't think it is really a misnomer. It can delegate the HW access to the kernel, which is the traditional way to do I/O in non-graphics contexts | 17:54 |
nemo | _abc_: what seriously? | 17:54 |
nemo | _abc_: got a source for that? | 17:54 |
_abc_ | muep: do you have an accelerated server? | 17:54 |
_abc_ | The docs say non accel server runs as root, accel runs as user if it can | 17:55 |
nemo | _abc_: an accelerated server is still accessing video memory through a relatively restricted interface, even if it is direct access | 17:55 |
_abc_ | Also are you on ascii? | 17:55 |
muep | I do not quite know what you mean by accelerated server | 17:55 |
nemo | I'm kinda astonished at the X "poking at kernel memory" thing | 17:55 |
muep | I have pretty good opengl support here | 17:55 |
_abc_ | nemo: non vesa etc? | 17:55 |
nemo | hm? | 17:55 |
_abc_ | VESA | 17:56 |
_abc_ | Anyway I was quoting what I read. | 17:56 |
nemo | _abc_: could you link me to where you read that? | 17:56 |
muep | I think the kernel does provide my processes a fairly low-level access to video hardware | 17:56 |
_abc_ | I think I am quoting 20 year old stuff when it did indeed run as root and had no silicon enforced access maps. | 17:56 |
nemo | ok... | 17:57 |
nemo | muep: yeah but that's a bit different than kernel memory | 17:57 |
nemo | muep: by that standard webgl is a major security hole (and IMO it is) | 17:57 |
nemo | it's just a different level of fail is all | 17:57 |
_abc_ | Iirc x86 had no silicon enforced memory access maps for processes running in kernel space. | 17:57 |
_abc_ | Unlike ioperm which limits such access for ports etc. | 17:58 |
nemo | and anyway, that gentoo guide seems to suggest debian could avoid the running as root if they really wanted to | 17:58 |
muep | I was not talking about kernel memory at all. but I would expect that there are vulnerabilities which would allow a nominally unprivileged but still video-capably application to bypass protections of the OS | 17:58 |
nemo | not super surprising since even the login manager could just be a more restricted user with the appropriate video device access | 17:58 |
nemo | assuming login managers even need acceleration | 17:58 |
_abc_ | kernel memory and video memory are one and the same when on a shared memory system | 17:58 |
nemo | muep: yeah. there were a fair # of said problems in earlier days of webgl | 17:58 |
muep | but it does not mean that it is running as root, unless you consider that in presence of bugs every unprivileged process is actually a root process | 17:58 |
nemo | muep: nowdays they sanitise shaders aggressively in part due to that | 17:58 |
_abc_ | Accelerated ones have separate video memory and there you can talk about not being able to poke in kernel memory with a video driver, in theory. | 17:59 |
nemo | muep: in part due to just crashing graphics card due to web page being not-fun | 17:59 |
_abc_ | Technically my current system is accelerated (puny, 10 year old) nvidia but uses shared memory. | 17:59 |
nemo | for a long while despite CORS protection on some cards you could read arbitrary textures from webgl O_o | 17:59 |
nemo | I remember when supporting hedgewars we'd sometimes get users reporting corruption in Hedgewars graphics | 18:00 |
nemo | they'd send us screenshots... | 18:00 |
nemo | it was parts of their UI showing up in game textures O_o | 18:00 |
nemo | that is, a texture ID we thought we had legitimate was... not... | 18:00 |
muep | there used to be a stage where most of our graphics drivers would barely be able to run correctly written programs | 18:01 |
nemo | the problem with webgl and video cards is kind of a rerun of the problem with web fonts - hooking remote access into tools that tended to trust their inputs | 18:01 |
nemo | and then shocker, hey, suddenly a ttf can corrupt freetype.. | 18:01 |
nemo | no wonder noscript blocks them by default. and that's not even getting into the insanity with ring 0 font parsing in windows | 18:02 |
nemo | muep: these days I think all the browsers feed the shaders into ANGLE first... | 18:03 |
nemo | but, yeah, still... | 18:03 |
_abc_ | Meanwhile, systemd kernel components process dhcp v6 and look at the cute bug they got just now... | 18:04 |
nemo | heh | 18:04 |
muep | s/kernel/network config tool/ | 18:04 |
nemo | in all fairness, the dhcp bug is in a piece that's not standard deploy... yet... | 18:04 |
nemo | but yeah, the code quality is apparently not great | 18:04 |
nemo | _abc_: did you read this one? https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.html | 18:05 |
muep | it has some good guidance. I often try to steer people away from the packed struct pattern | 18:06 |
_abc_ | Not that Java style serialization is better in any way. Fortunately I do not deal with any of this usually. | 18:08 |
nemo | muep: speaking of alignment tangentially, and debian, and, well hedgewars from above graphics chat ... | 18:08 |
nemo | muep: we've been broken on 32 bit debian for a year now thanks to freepascal and SDL2 ☹ | 18:08 |
nemo | took us a while to realise what was going on | 18:09 |
_abc_ | nemo: heh. | 18:09 |
muep | _abc_: you mean that buf[0] * 256 + buf[1] ? I think it is way better. for one, it works pretty much the same in pretty much any language that you might be using | 18:09 |
_abc_ | muep: unless you're on big endian arm or mips probably | 18:10 |
_abc_ | muep: Which machinesdo exist. | 18:10 |
muep | _abc_: how so? | 18:10 |
muep | that bit is for unserializing, not serializing | 18:10 |
_abc_ | I'm guessing it would matter? | 18:10 |
muep | it specifically would not matter | 18:11 |
_abc_ | One hopes. | 18:11 |
muep | no need to hope. because you write your code to pick the bytes always in the same order | 18:11 |
_abc_ | I think the htoni() ntohi() functions were not created for nothing. | 18:11 |
nemo | https://bugs.freepascal.org/view.php?id=15582 if you guys happen to use freepascal for anything for some reason ☺ | 18:11 |
nemo | workaround for now will be to use the pas2c thing unc0rr wrote long ago to compile using clang instead for next debian 32 bit release - long-term we're just gonna use rust | 18:12 |
muep | they are a different way to approach the problem, but like the writer of that article, I would prefer code that just naturally does the same things regardless of endianness | 18:12 |
nemo | muep: well. there's also the question of why the hell are they constantly writing new code for crap that's existed for decades | 18:12 |
nemo | muep: would make sense if it was implemented in, oh, node.js 😉 | 18:12 |
nemo | they being systemd... | 18:13 |
muep | this would always read the number as big-endian, regardless of HW architecture: some_number = buf[0] * 256 + buf[1] | 18:13 |
_abc_ | Poettering said in his interview linked above that he will take over the world, unifiy all linuxes, and they will be all faster and better due to him | 18:13 |
nemo | _abc_: heh. even if he was joking about unifying all linuxes under his control, it's probably a joke that's revealing | 18:14 |
_abc_ | And that will create pax aeterna (my comment) | 18:14 |
_abc_ | He was not joking. | 18:14 |
_abc_ | it's not his fault, the voices in his head tell him what to do... | 18:15 |
nemo | Pax Æternum ? | 18:15 |
nemo | my latin conjugation is nonexistent but I looked that one up out of curiosity | 18:15 |
_abc_ | The hubris of any non institutionalized individual claiming everyone else on this planet is wrong in anno domini 2011 is absolutely remarkable from a medical point of view. | 18:15 |
_abc_ | Technically I do not look these things up since my local language is Romance and Latin based. | 18:16 |
_abc_ | And the modern version of that saying is pace eterna. | 18:17 |
ejr | so ibm is going to buy red hat - i guess that makes corporatisation of systemd even less unavoidable | 18:51 |
cirdan | ejr: depends. i would hope ibm is smart enough to shitcan that trash | 20:23 |
muep | to me it does not seem like RH is doing all systemd development | 20:32 |
Digit | glimpsing at https://www.gnu.org/software/hurd/open_issues/systemd.html linked in another chan with the words "hurd is dead", i get the impression "pfff. debiand propblems." and maybe, hurd's fine devuan-wise. ? i mean, even if dormant and lacking manpower, still, nothing impeding, right? | 22:08 |
pankerini | I think GuixSD will be the first full-fledged GNU/Hurd distribution and they don't even use systemd. | 22:17 |
Centurion_Dan | Digit: sure... we may even take up the port one of these days... | 23:11 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!