Due to the wikileaks dump of Vault7, we know there is a 0-day against HALd. Since HALd is mostly unused on the linux side, its very unlikely that it will get patched since most distros are using systemd now.
gvfs can build without HAL support. I ran gvfs-lite on linux for quite a while back in the days that I was a linux distro dev.
Should we disable hal in gvfs for this reason? I realize that some programs that rely on gvfs with hal will loose some functionality, so it comes down to the issue of what's more important. Security or Features.
I personally side with security, but this isn't my port, so it's not my choice to decide.
(In reply to q5sys from comment #0)
> Due to the wikileaks dump of Vault7, we know there is a 0-day against HALd.
> Since HALd is mostly unused on the linux side, its very unlikely that it
> will get patched since most distros are using systemd now.
> gvfs can build without HAL support. I ran gvfs-lite on linux for quite a
> while back in the days that I was a linux distro dev.
> Should we disable hal in gvfs for this reason? I realize that some programs
> that rely on gvfs with hal will loose some functionality, so it comes down
> to the issue of what's more important. Security or Features.
> I personally side with security, but this isn't my port, so it's not my
> choice to decide.
Wouldn't this question be better directed at HAL; or rather,
IOW why target ports that use HAL, when (apparently) HAL
is the problem?
Just my 0.2¢ on the matter. :-)
Because hald is mostly abandoned by Gnome and the FreeBSD code is really, really kludged to try to imitate the Linux code when our kernel does not have the APIs that the linux code wants. even on the Linux side, it is widely considered a really ugly, hackish thing and that is why the Linux devs have mostly moved on to udev and some other tools (devkit?). FreeBSD seems to favor the use of devd for "easy" instances and modifying codes to work with it or using a FreeBSD udev that is more or less a wrapper on devd, that implements the udev API and not requiring changes to the calling code. I see that the latest X11 test code implements both and allows you choose which to try.
Porting hald to FreeBSD was an almost heroic effort, but it is still a kludge and getting rid of it is a very good idea, IMHO. I really can't see anything but trivial fixes to hald as being worth the effort, but YMMV and patches are always welcome. Just be ready for some nausea when you look at the hald code. At least that was my reaction when I first looked at it. Not really awful code (well, some is) but just a broken first attempt to solve a problem.
I'd also mention that the FreeBSD hald is heavily modified and it is quite possible that this 0-day is not even relevant to FreeBSD. (No, I am not volunteering to try to find out.) I am not sure what features will be lost if hald is removed from gvfs, but I suspect that it will impact me. I'm building without HAL now to find out.
I didn't send a BR in to HAL because at this point I dont know what can even be done. To my knowledge exploit code has not been released, so we'd have to try to figure out what the exploit is and then fix it.
The only thing I could come up with at the time was 'remove HAL', but I felt like that request should come from someone more senior than I. Also there's the issue that if that is done, anything depending on HAL like gvfs would have to be modified not to use HAL... which is exactly what this BR is about.
I dont want to speak for anyone, but I'm pretty sure that no one really wants to dig around in HAL to try to discover the problem and patch it consider it's no longer being maintained on the Linux side. The last patch on the linux side was 2011 per https://cgit.freedesktop.org/hal/log/
As for if this exploit is viable on FreeBSD, PC-BSD was explicitly stated as being vulerable, and since PC-BSD was FreeBSD with pre-configured desktops. TrueOS has diverged from FreeBSD stable since it's based on 12.Current, but the older PC-BSD versions were in lock step with the FreeBSD stable branches. So I'd assume, perhaps incorrectly, that if (for example) PC-BSD 10.x with HAL was vulnerable, that FreeBSD 10.x would be as well... assuming HAL running on that system.
I'll not argue that you both make good points.
Because you do. :-)
My last experience with Xorg, on a (then) fresh install
of 11 (about 5mos ago). Was that it didn't work w/o
enabling HAL in rc.conf(5). I didn't verify that fact
on my now current && fresh install of -CURRENT (12).
I just installed/enabled it *assuming* I'd run into
trouble, if I didn't.
I had just set out to tackle the earlier work on
HFS(plus) for FreeBSD. That is, finish/bring it up to
current FreeBSD. But before I get too involved, maybe
I'll have a look, and see just "how bad" HAL(D) really
is, and whether reworking/fixing/... is/would be a
I'll give it a look, and report back (tomorrow(ish)).
HAL support is already removed in gvfs 1.32, so hal volume monitor is likely to be disabled when GNOME is updated to 3.24.
(In reply to Ting-Wei Lan from comment #5)
Do you know when GVFS 1.3x will make its way into the ports tree? The Ports version is still 1.2x
(In reply to q5sys from comment #6)
GVFS is usually updated together with GNOME, so GVFS 1.32 will be available in ports once GNOME 3.24 gets committed. GNOME 3.24 was released just a few weeks ago, and GNOME 3.22 update was blocked by issues in GDM and ConsoleKit.
(In reply to Chris Hutchinson from comment #4)
Did you tried in xorg.conf:
Option "XkbRules" "xorg"
Option "XkbModel" "pc104"
Option "XkbLayout" "us,…"
Option "Protocol" "Auto"
Option "Device" "/dev/sysmouse"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
Option "AutoAddDevices" "off"
Option "AllowEmptyInput" "off"
gvfs does not have anymore a dependency on hal