Windows 98 SE on QEMU

I had Journeyman Project Turbo working on Windows XP and Windows 3.1. I wanted to continue the effort with Windows 98 SE. I used QEMU with pc-i440fx, AC97 audio, RTL8139 network, and VGA video. Steps that worked:

  1. Install Windows 98 SE from the ISO
  2. Configure “Plug and Play BIOS” to use PCI bus driver as documented by SoftGPU
  3. When the network device is found, use the RTL8139 floppy image from archive.org
  4. Continuing the SoftGPU documentation:
    1. Turn on DMA for HDD and CD-ROM
    2. Change Network Logon to Windows Login
    3. Download and install 7zip
    4. Open 7zip then in “Tools > Options” associate it with the zip extension
    5. Download and configure the sound card with AC97 drivers
  5. Copy “D:\Win98” from Windows CD to “C:\Windows\Options\Cabs”. In regedit, navigate to “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup” and change “SourcePath” to the new path.
  6. Install SoftGPU via its ISO. You can disable the DirectX 9 install

Sharing files with WebDAV

The Internet is essentially limited to HTTP (no HTTPS). Any file-sharing needs to be unencrypted. WebDAV is a pretty reasonable tool for the circumstance. To access from Windows 98, it’s as easy as My Computer > Web Folders > Add Web Folder, including “http://” in its location.

For the host, I’m running Linux and chezdav from phodav proved pretty easy (even if it has very permissive defaults). For a publically writable directory:

chezdav --no-mdns -P path/to/folder

To protect it with a password, use htdigest from apache:

htdigest -c webdav.digest myrealm myusername
# enter password
chezdav --no-mdns -P path/to/folder -d webdav.digest

I’ve good experience with the webdav server in Go, and a minimal Go webdav server works well. davserver from PyWebDAV3 also looks promising, but I didn’t try it out.

Journeyman Project Turbo on Windows 3.1

I was interested in playing Journeyman Project Turbo, which was difficult to play as a kid because Packard Bell provided the game with our Pentium 133, but didn’t include a manual with the disk.

It doesn’t work under Wine 9.12 with DOSBox installed, with winevdm crashing. It runs pretty easily on 32-bin Windows XP. But I hadn’t ever installed Windows 3.1 before, so I figured I’d see what it takes.

My Journeyman Project disk image is in a CUE+BIN form, so I converted it to an ISO with bchunk:

bchunk jman.bin jman.cue jman.iso

Journeyman Project Turbo requires Video for Windows 1.1e, but didn’t include it on the disk I was using. I found a copy on WinWorld. After extracting, I named the image vm1.1e.img for easier typing in DOS.

For the Windows 3.1 install, I found the Medium post Let’s Install Windows 3.1 in Dosbox helpful.

I have Windows 3.1 as 6 disk img files. Dosbox can mount such a disk via imgmount a disk1.img -t floppy, but won’t let you change the mounted disk while running Windows setup. So instead, you have to use a folder, mount the folder (e.g., mount a curdisk), exchange the contents of the folder when needed during the setup, and press Ctrl+F3 for dosbox to reload the directory. Easier though, is to copy all the contents of all the disks into the directory up-front.

# Mount all the images, then
mkdir win31
cp WIN31DISK*/* win31/

I used S3 drivers for video and SB16 drivers for audio. I downloaded S3DRIVERS.ZIP and SB16W3X.ZIP and extracted them their own directories.

With the Journeyman Project software dependencies ready, the install:

pacman -S dosbox
# installed 0.74.3

mkdir c
dosbox
mount c c
mount a win31
a:setup
# Enter (Continue)
# Enter (Express Setup)
# -- Figure it out -- (e.g., no printer)
# Return to MS-DOS
mount -u a
mount a SB16W3X
a:install
# Enter (Continue)
# Enter (Full Installation)
# Press down to select Windows path. Enter to select. Enter to accept C:\Windows
# Enter (Continue)
# Press down to select Interrupt setting. Change it to 7, since
#     `~/.dosbox/dosbox-0.74-3.conf` has an `[sblaster]` section with `irq=7`
> Enter (Continue)
> -- Install is much, much slower than Windows 3.1 --
> Backup MIDIMAP.CFG
> Enter (Exit)
mount -u a
mount a S3DRIVERS
# Current directory must be c:\WINDOWS directory
setup
# "Accept the configuration shown above." should be selected. If it is trying
#     to install, you weren't in the WINDOWS directory
# Move up to Display, Enter. Go to bottom and select "Other". Enter for A:\
# Select third: 640x480 64K colors. Prevents graphical glitches in-game
# Enter to "Accept the configuration shown above."
exit

dosbox
mount c c
imgmount a mv1.1e.img -t floppy
c:
cd windows
a:setup
# You should hear "tada" startup sound as Windows starts
# Go through install
# "Restart Now". Quit dosbox

dosbox
mount c c
# Use z:imgmount if copied to autoexec.bat
imgmount d jm.iso -t cdrom
c:\windows\win
# File Manager. Select drive D
# Run jman.exe. Tell it to find the files in D:\ if it asks

You can add the last two commands to c/AUTOEXEC.BAT and then run with dosbox c/AUTOEXEC.BAT.

Flatpak Permission Survey

When working through yesterday’s post, half-way through I found the 2020 flatkill.org post and the TheEvilSkeleton response. The response was early 2021 and felt hopeful for the future.

One very different take is they were both focused on popular applications. I was focused more on productivity applications and those that I could choose between my distro and Flatpak to get a feel of Flatpak, apples to apples. But the biggest concern is the statistics about 27 out of 50 popular applications not having --filesystem=host or --filesystem=home. As I saw yesterday, there are other ways to break out of the sandbox. I figured I’d take a look myself, but unfortunately the popular apps today are mostly emulators and Blink-based, so things look pretty bleak with that set. I think it is a skewed set due to the Steam Deck, and worse than the majority of packages.

The following is from the first page of popular on Flathub, sorted hopefully by popularity. It is the top 30 items, because the pages hold 30. The first three columns are straight from Flatpak’s website. “Verified” is whether the packager has a blue check. “Security” is the sandbox permission badge color. “Concerning permissions” is my own selection of permissions that are concerning. I made some arbitrary decisions on what to include, mostly focusing on sandbox escapes and unfortunate mixes of permissions. In particular, it includes --device=all but not pulseaudio, as access to all devices might have more implications than just webcam access.

Name Verified Security Concerning permissions
Google Chrome 0 Red –device=all –socket=x11 –share=network –talk-name=org.freedesktop.secrets –filesystem=xdg-run/dconf Why so much file access?
Firefox 1 Red –device=all –share=network
VLC 0 Red –filesystem=host –device=all –socket=x11 –share=network –talk-name=org.freedesktop.secrets
Discord 1 Red –device=all –socket=x11 –share=network
Dolphin Emulator 0 Red –filesystem=host:ro –device=all –socket=x11 –share=network
RPCS3 0 Red –filesystem=home:ro –device=all –share=network –filesystem=/media
PPSSPP 1 Red –device=all –socket=x11 –share=network
DuckStation 1 Red –device=all –socket=x11 –share=network
Citra 1 Red –filesystem=host:ro –device=all –socket=x11 –share=network
Brave Browser 0 Red –device=all –socket=x11 –share=network –talk-name=org.freedesktop.secrets –filesystem=xdg-run/dconf
RetroArch 1 Red –filesystem=host –share=network
xemu 0 Red –filesystem=host:ro –device=all –share=network
melonDS 1 Red –filesystem=home –device=all –socket=x11 –share=network
PrimeHack 1 Red –filesystem=host:ro –device=all –socket=x11 –share=network
Telegram Desktop 1 Red –device=all –share=network
Spotify 0 Red –device=all –share=network
Visual Studio Code 0 Red –filesystem=host –device=all –socket=x11 –share=network –socket=ssh-auth –talk-name=org.freedesktop.secrets
Steam 0 Red –device=all –socket=x11 –share=network
ProtonUp-Qt 1 Red –filesystem=~/.bashrc –device=all –socket=x11 –share=network
Microsoft Edge 0 Red –device=all –socket=x11 –share=network –talk-name=org.freedesktop.secrets –filesystem=xdg-run/dconf
Flatseal 1 Red –filesystem=xdg-data/flatpak/overrides:create
Bottles 1 Red –device=all –socket=x11 –share=network –system-talk-name=org.freedesktop.UDisks2
ScummVM 1 Red –filesystem=home –device=all –socket=x11 –share=network
Protontricks 1 Red –device=all –socket=x11 –share=network –system-talk-name=org.freedesktop.UDisks2
Extension Manager 1 Yellow –share=network
GIMP 1 Red –filesystem=host –socket=x11 –share=network
OBS Studio 1 Red –filesystem=host –device=all –socket=x11 –share=network
Heroic Games Launcher 1 Red –device=all –filesystem=mnt/media –filesystem=~/.local/share/applications –socket=x11 –share=network
LibreOffice 1 Red –filesystem=host –share=network –filesystem=xdg-run/gvfsd
qBittorrent 1 Red –filesystem=host –share=network

Some comments:

  • 2/3 have a verified packager
  • The security badge is normally red
  • Every top app has --share=network
  • Every top app, except for Extension Manager, has --device=all or --filesystem=host
  • 2/3 have --socket=x11

While going through the manifests, I noticed that --talk-name doesn’t show up in the listed permissions on the Flatpak website. That is very serious, as --talk-name=org.freedesktop.secrets seems important and access to the systemd service provides a trivial sandbox escape. I tried to guess which dbus services are “dangerous”, and some I looked up their definiton to make a judgement. Strangely, I couldn’t find the definition of org.gnome.Software.

Some permission combinations are a problem without sandbox escape. As examples, there’s little need to escape from the sandbox with --filesystem=home:ro --share=network or --talk-name=org.freedesktop.secrets --share=network.

Only a minor concern, but I noticed that --metadata=X-DConf=migrate-path= isn’t listed on the Flatpak website. This is a very good feature that avoids sharing write access to all settings. But I’d have to investigate more to see if just read-only access to settings can be a problem. It won’t contain secrets, but there’s so many options it makes me wonder.

My programs of interest

These are the programs that I was looking at when making yesterday’s post, with a few additions. They are mostly GNOME/GTK, but with some oddballs mixed in. There are both very old GNOME programs (Videos, a.k.a. Totem) and some more recent remakes (Image Viewer, a.k.a. Loupe). I chose these as an “interesting” set. They are sorted by name.

Name Verified Security Concerning permissions
Boxes 1 Red –filesystem=host –device=all –share=network –talk-name=org.gnome.Settings –filesystem=xdg-run/dconf
Calculator 1 Yellow –share=network
Characters 1 Green
Connections 1 Yellow –share=network
Disk Usage Analyzer 1 Red –filesystem=host –filesystem=xdg-run/gvfs
Document Scanner 0 Red –device=all –share=network
Document Viewer 1 Red –filesystem=home:ro –filesystem=xdg-run/gvfsd
Ear Tag 1 Red –share=network
File Roller 1 Red –filesystem=home
Flips 0 Red –filesystem=home
Foliate 1 Red –share=network
gedit 0 Red –filesystem=host –filesystem=xdg-run/gvfsd
GHex 0 Red –filesystem=host –filesystem=xdg-run/gvfsd
GnuCash 0 Red –filesystem=host –share=network
gThumb Image Viewer 0 Red –talk-name=org.freedesktop.secrets –filesystem=xdg-run/gvfs
HxC Floppy Emulator 0 Red –socket=x11
Image Viewer 1 Red –filesystem=host –filesystem=xdg-run/gvfs
KiCad 1 Red –filesystem=home –socket=x11 –share=network
Meld 0 Red –filesystem=host
Piper 0 Red –socket=x11
Remmina 1 Red –filesystem=home –device=all –share=network –socket=ssh-auth –talk-name=ca.desrt.dconf –filesystem=xdg-run/gvfsd
Rhythmbox 0 Red –share=network –filesystem=xdg-run/gvfsd
Videos 1 Red –device=all –share=network –talk-name=org.gnome.OnlineAccounts –filesystem=/run/media –filesystem=xdg-run/gvfs

Some comments:

  • 1/2 have a verified packager
  • The security badge is normally red, but greens aren’t entirely mythical
  • Four have --share=network without other relatively problematic permissions
  • Most that are missing --share=network have a trivial sandbox escape
  • Foliate is only red only because it has --filesystem=xdg-run/speech-dispatcher:ro.

With this set of apps, we are in the murky sandbox territory that I was wrestling with yesterday. A sandbox might help some of these. But the permission list exposed to users is insufficient for determining if the app is sandboxed more than in name. It also doesn’t really matter, because with almost universal red security badges, the user is required ignore it. If --share=network allows access to the session bus on my distro, then only Characters is safe, ignoring upgrades adding permissions and assuming I trust Flatpak after all this.

Flatpak Permissions on Upgrade, Unravelled

Flatpak has been around for a while, but I’ve not cared about it. I got interested in Fedora Silverblue as a ChromeOS replacement so have been trying Flatpak out on Arch.

It has a sandbox, which is nice, but what is the security model of the sandbox? I can see the permissions before installing a package, but what if those permissions change? Is the sandbox there to restrict the impact of a remote-code-execution of a hacked app, or is it there to protect me against the software packager? Glancing through pages wasn’t clear.

The main difference between the options is, “what happens when an app adds new permissions to its manifest?” If Flatpak happily upgrades it, then the sandbox trusts the software packager. But I didn’t find any documentation about how added permissions are handled.

I followed the org.flatpak.Hello example, building the app and adding it to a repository, then installing the app. I then rebuilt the app to see what the ordinary flow looked like:

$ flatpak update
Looking for updates…


        ID                  Branch   Op   Remote          Download
 1.     org.flatpak.Hello   master   u    tutorial-repo   < 601 bytes

Proceed with these changes to the user installation? [Y/n]:

I then appended to org.flatpak.Hello.yml:

finish-args:
  - --share=network

I rebuilt the app and then updated:

$ flatpak update
Looking for updates…

New org.flatpak.Hello permissions:
    network



        ID                  Branch   Op   Remote          Download
 1.     org.flatpak.Hello   master   u    tutorial-repo   < 647 bytes

Proceed with these changes to the user installation? [Y/n]:

Well, that’s good that it tells me, but it also isn’t the least bit scary and is easy to miss, especially if there are many updates. I’m also left wondering what happens with automatic updates. flatpak update --assumeyes is probably a bad idea (which isn’t mentioned in --help), but --noninteractive looks promising:

$ flatpak info --show-permissions org.flatpak.Hello
$ flatpak update --noninteractive
Updating app/org.flatpak.Hello/x86_64/master
$ flatpak info --show-permissions org.flatpak.Hello
[Context]
shared=network;

It happily accepts the new permissions without any notification. The output is identical to when permissions stay the same. I had expected it to either error or ignore the update. I’d gladly accept it making an override that denies the new permission, but it doesn’t do that either. I wasn’t really expecting that, because there wasn’t an option to do that interactively.

Now, you could argue “CLI is for advanced usage; use Gnome Software.” Unfortunately, this hello world example doesn’t show up at all in Gnome Software, so I couldn’t test. But if I search specifically for gnome software upgrade change permission then I can find Gnome Software issue 943: UX for Flatpak permission changes on update. It shows Gnome Software is in a good place, but it doesn’t fill me with confidence about Flatpak overall. If I had Discover installed and logged into KDE, would I still be okay?

Installs default to system-wide

Using flatpak list I can see apps installed in the “system” Installation. This is not clear in Gnome Software. Upgrading these apps changes the permissions for all users, yet I don’t get a “you are about to change your system” dialog before using elevated privileges. Gnome Software does sorta tell me if I go to Software Repositories and see “System Installation • 3 apps installed”.

Apparently it is system-wide because Flathub is configured in /etc/flatpak/remotes.d/. If the repo is system-wide, then the install is system-wide. I can accept that logic, but this was done by default by the Arch flatpak package. The Fedora package doesn’t include Flathub. Flatpak is aware of this in their setup docs: Arch vs Fedora. They encourage the system installation in their docs, and the flatpak CLI defaults to system installation.

Easy mistakes with flatpak CLI

I also discovered that flatpak permission-show and flatpak permissions don’t do what they would appear. They show only some of the permissions; the extra permissions granted, above those in the app’s manifest. They also report no warnings/errors if the app name is mispelled. Very easy to be misled.

flatpak override is poor as well, as there does not seem to be a way to list all overrides; you need to dig into ~/.local/share/flatpak/overrides, which at least is documented in man flatpak-override.

$ flatpak override --user --unshare=network org.flatpak.Hello
$ flatpak override
error: Permission denied
$ flatpak override --show
$ flatpak override --user
$ flatpak override --user --show
$ flatpak override --show org.flatpak.Hello
$ flatpak override --user --show org.flatpak.Hello
[Context]
shared=!network;

There’s no UIs for those things in Gnome Software. Given how much I’ve heard about the sandbox in Flatpak, I’m disappointed in the cavalier security usability stance.

How can a user accept permissions?

While doing the above I wondered about Flatseal, because it is particularly powerful in a “can attack you” sense. Flatseal lists “No Network Access” in its permissions in Gnome Software, but it also has an entry for “Arbitrary Permissions” with the description “Can acquire arbitrary permissions”. It seems in that case the various green “No $X access” should be removed.

How bad are other cases? If an app has access to “Pictures folder,” it seems that is probably mostly predictable. But isn’t it trivial to escape the sandbox with “Session Services” (--socket=session-bus) using systemd-run? How would a user know that “No Network Access” is meaningless when the service “Can access D-Bus services on the session bus”?

But also an app might have access to the session bus because of abstract Unix sockets. From the Flatpak Sandbox Permissions Reference:

Giving network access also grants access to all host services listening on abstract Unix sockets (due to how network namespaces work), and these have no permission checks. This unfortunately affects e.g. the X server and the session bus which listens to abstract sockets by default. A secure distribution should disable these and just use regular sockets.

On Arch, lsof -U | grep @ shows dbus-broker and gnome-session available as abstract sockets.

If an app has write access to the XDG config directory (--filesystem=xdg-config) it can write configuration for systemd to start a service on next login. Write access to the home directory can write .bashrc. Write access to all settings can change which program is executed with my custom keyboard shortcuts.

Having the sandbox in many of these cases seems useless, because it takes 10 minutes for an attacker to work around it. This isn’t even to the level that “defense in depth” becomes helpful. I think the only benefit of the sandbox for these is when developing an application and incrementally making your application sandbox-ready. But the user should be told there isn’t a sandbox. Even if it is nominally present, it isn’t providing its function.

Gnome Software does give such permissions red and yellow security levels, but the explanations of the permissions undersells their power and then acts like other permissions are still restricted.

Relatively small beans

When opening a file with a Flatpak app in Nautilus and xdg-open, my entire environment is copied onto the command line and visible through ps. I understand some OSes allow users to view each other’s environment and that secrets need to be shared through files or pipes. But this is still surprising.

By poking around with the CLI I noticed that every time I open a file in a portal or with File Roller it adds a new (permanent?) permission for the opening app. But Gnome Software doesn’t have a UI to show me the added permissions. And the permissions are kept even if I uninstall and reinstall the app.

I can clear out all permissions for a specific app using flatpak permission-reset APP_ID or all apps with flatpak permission-reset --all. Although the permission rows remains, listing each opened file, just with the app removed. To delete the row I need flatpak permission-remove TABLE ID, but each row has to be deleted individually.

Takeaways

I started with a very precise concern, didn’t get a clear answer, and now I have additional concerns. Before this investigation I had thought “if an app doesn’t have both network and data access, then that is progress.”

But I don’t think Flatpak is actually communicating the security impact of permissions. And while I now know the full severity of a longer list of risky permissions, what attacks am I not noticing? And do I actually trust Flatpak that a fully-locked-down “all green” app can’t easily escape given so much wasted effort on permissions elsewhere? (I accept that the sandbox can be escaped, but I want to avoid someone knowledgable only needing 10 minutes to break out.)

Fedora (and Silverblue) doesn’t use Flathub by default. That seems like a wise decision. On that system I could use Flatpak without much worry as it is just a different package format for the distro.

Looking through the ~20 apps I’m interested in, all of them show red in Gnome Software except for two yellows: “Calculator” and “Connections,” both of which have network access (Calculator looks up currency exchange rates). Flathub is looking like just another distro but with each user needing to vet most packagers.

Hugo Migration

I converted the site from XSLT to Hugo. If you notice something awry, please let me know. I’m hoping the change makes posting easy enough for me to do it more frequently.

Hugo felt reasonably natural to me. It isn’t that far away in concept from phppen used by the main ersoft.org, except it isn’t using PHP nor MySQL for its backing store. There were some things that needed figuring out, but that was partly because I wanted to match the existing page structure. The only strong oddity was it not having built-in Atom support.

Surprisingly it had trouble computing URLs for attachments to posts. That same problem was a pain when implementing the XSLT-powered code. I’m happy for layouts/_markup/, as it allows fixing the problem without shortcode, which would have made the posts depend on Hugo. Looks like the next Hugo version will improve the deault and I might be able to remove my custom code.