Review dom0 small edit of /usr/lib/qubes/icon-receiver. Is it safe? Any security notes?

User Support
,
1

I wanted to have icons that are not tinted. I could achieve this by editing /usr/lib/qubes/icon-receiver as follows: replaced icon_tinted with icon at lines 300 and 307, and commented line 298 as not necessary.

Comparasion

Before:

async def retrieve_icon_for_window(self, reader, color):
        # intentionally don't catch exceptions here
        # the Image.get_from_stream method receives UNTRUSTED data
        # from given stream (stdin), sanitize it and store in Image() object
        icon = await Image.get_from_stream_async(reader,
            ICON_MAXSIZE, ICON_MAXSIZE)
        # now we can tint the icon to the VM color
        icon_tinted = icon.tint(color)
        # conver RGBA (Image.data) -> ARGB (X11)
        icon_tinted_data = self._convert_rgba_to_argb(icon_tinted.data)
        # prepare icon header according to X11 _NET_WM_ICON format:
        # "This is an array of 32bit packed CARDINAL ARGB with high byte
        # being A, low byte being B. The first two cardinals are width, height.
        # Data is in rows, left to right and top to bottom."
        # http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html
        icon_property_data = struct.pack(
            "II", icon_tinted.width, icon_tinted.height)
        # and then append the actual icon
        icon_property_data += icon_tinted_data
        return icon_property_data

After:

async def retrieve_icon_for_window(self, reader, color):
        ....
        #icon_tinted = icon.tint(color)
        # conver RGBA (Image.data) -> ARGB (X11)
        icon_tinted_data = self._convert_rgba_to_argb(icon.data)
        ....
        icon_property_data = struct.pack(
            "II", icon.width, icon.height)
        ....

Maybe you’re laughing at me right now: “What does this have to do with security?” But, how would I know? I say it may be that Qubes OS developers depend on what they wrote? Any change from user would break everything? Does this even exist in any OS or I’m mistaken in my thinking?

2

I’m not sure how dnf handles package upgrades for files that were modified after installation, it may not update it any more, so if there is a fix / update / change to a manually modified file, you will keep your old file that may create issues in the future because it’s not in sync with everything else.

Let’s imagine there is a huge change how icons works in Qubes OS 4.3, if you upgrade from 4.2 you will not have this exact file upgraded.

3

It should be safe. I have been doing this for around one year. Your changes will be overwritten on every update to qubes-gui-daemon. Which is going through a lot of changes in recent months (maybe once or twice a month).

Take my tweaked icon-receiver as an example. I have been doing a more complex job. What I have done is I have disabled the original icon-receiver via a .desktop file and installed my own via another .desktop file. My icon-receiver loads the original class and overrides only the required method.

It has something to do with security. You are sacrificing Icon tinting for your personal ease. And icon tinting is supposed to be a security feature. What I did was a complex series of changes to disable tinting only for selected trusted Qubes.

It is always updated on every update to qubes-gui-daemon. It is possible to find the origin of files in Fedora via rpm -qf $file. Then we know to which package the file belongs and how to recover it via dnf reinstall.

I am on Qubes OS 4.3 development branch at this moment. And I have been using the old tweaked icon-receiver from R4.2. Not so much has been changed till now.

2 Likes