Nupro X3000 RC – a solid high quality supplement to your Linux Audio

A friend asked me what sound equipment I use on my Linux machine. She wanted to to buy some new decent speakers. I had to make a similar decision a year ago. Coming to a conclusion back then became a more difficult process than I had expected.

I admit that I am a total amateur regarding sound equipment. I have not changed my sound cards (Asus Sonar D2X, Creative X-Fi Titanium, Onboard High Definition GM206) for a long, long time. And I do not hear as well as in my younger years. But during Corona and home office times I became really discontent with my old Creative speakers. One cannot all the time wear headphones. So some new speakers for my Linux workstation became a topic on my private agenda.

Questions ahead of a decision for some speakersfor your PC

When I seriously started thinking about some investment the following questions came up:

A surround system? Active or passive boxes? Suitable for a shelf or standing on the floor? Do you want to use the speakers later also in other contexts than just as a background equipment in your working room? What is appropriate for your room size? Connections cable (copper, optical?) based or WiFi or Bluetooth based? In my age when hearing capabilities are reduced: Will high end properties make a difference at all? And the most limiting factor: budget.

Taking all these factors into account will certainly lead to very personal decisions. So, when I make an explicit recommendation here - take it with caution and a grain of salt.

Guidelines to choosing speakers for a non-professional PC environment

Here are the personal guidelines which I followed - after I had read reviews, listened to Teufel and Edifier speakers at friends and listened to a relative expensive Logitech surround system at my nephew. You may have other references, other budgets and hear much better and more differentiated than I do. So relax if you come to other conclusions.

And do not forget: I am talking about sound equipment on a PC for background music enjoyment in a working room - not for professional objectives and High End specialists.

  • Recommendation 1: If you are interested in sound quality and are a music enthusiast - forget about surround systems. Quantity (many speakers) almost always enforces quality compromises, which you are going to hear in the end. Better invest your money into a 2.0 or 2.1 system which fits the (probably) limited size of your working room.
  • Recommendation 2: If your room size is up to 30 square meters, invest into relatively small speakers - but of studio quality. They will give you a much more pronounced and positioned sound than surround systems. Regarding money think of speakers which you later can supplement with a sub-woofer - e.g. in case you want to move the speakers to a larger room sometime in the future.
  • Recommendation 3: Regarding bass: I am a heavy metal friend - sometimes. I have my phases and periods regarding music ... Sometimes I like Jazz, only. Bass in the named two cases has a different meaning to me - but in any case I do not like resonances of my speakers. The stereo speakers alone should already provide a solid, broad and resonance free bass fundament - without a sub-woofer. A sub-woofer can deliver an extra feeling in the case of metal - but for Jazz and classical music I would not consider a sub-woofer as really relevant. So go for some solid speakers with the option of adding a sub-woofer in the future.
  • Recommendation 4: Do not underestimate the effect (or limitations) of the DAC in your sound card! At a certain quality level of your future speakers you are probably going to hear differences. So - if you are lucky and can invest into expensive speakers rethink your sound card equipment, too.
  • Recommendation 5: Do not underestimate the effect of the boxes' positions in the room. Also in small rooms you will experience bass line effects around 100 Hz or so if you place your boxes in the room's corners. This leads to the point that you may want some equalizer option to optimize the bass base a bit. Well, Linux or at least most music applications for Linux supply you with equalizers; but it is a nice option to be able to do something at the (active) boxes themselves to get a basic "direction" into your sound environment. And here we would also like to have the option of defining some "presets".
  • Recommendation 6: Active boxes or amplifier? A very difficult question! In a PC and mobile environment I would tend to active speakers, but ... The amplifier technique today is so good that at least in my case my hearing deficits are certainly more important.
  • Recommendation 7: Wifi? personally, I would say: Yes, you should have this option. But if so: Go for a 5 GHz band. And check whether your router offers you the option to define the precise band it should work on or whether the router automatically adapts the precise channel to avoid disturbances with other sources.
  • Personal opinion some people certainly would like to crucify me for: Teufel speakers seem to be a bit overestimated. Personally I do not think that the quality-price relation is convincing. After having heard to a standing speaker pair I think that the balance between bass and mid-range frequency sound is strange. Very vague in a way.

Nupro X3000 speakers as a solid option for a reasonable price

Taking all these aspects into account I ended up with a decision for (active) Nupro X3000 RC speakers from the producer "Nubert electronic GmbH".

So far, I have not regretted this decision for a second. These boxes did not disappoint me - neither with Classical music, Jazz nor Heavy Metal.

Though admittedly, if you want to feel bass and drumming these boxes improve their performance in larger rooms certainly a bit when combined with a sub-woofer (which I personally use at a second sound card). But this happens at rare occasions ...

Ease of setup?

The setup of the active boxes is very simple; the explanations on the accompanying leaflets are fully sufficient. You define everything by a 4 direction control button on one of the speakers. The button and a small display are hidden behind magnetically attached front panels.

Basically, you just have to define a master and a slave speaker in the first setup round and choose a connection to your sound source - here to the output connectors of a PC soundcard. In the end I used the "aux" entry and still live with an analog cable based connection between the sound card and the main box plus a digital coax cable between the boxes. (Due to the speakers' distance I had to buy an additional coax cable. It disappears behind a shelf).

But a WiFi connection between the speakers works very well, too. I could see no major conflict with the 5 GHz channels occupied by the WLAN routers in my surroundings.

The basic connection options to your PC and sound card are manifold: The USB-interface of the Nupro sound processor appears as an USB sound card on your PC; this "sound card" is well supported on my Opensuse and KDE based Linux systems. You just have to chose the SPDIF stereo variant of the two options offered in the KDE/Phonon sound settings.

Besides an USB cable the connection cables delivered with the speakers include an optical cable with TOSLink adapters, a SPDIF cable and analog cables with cinch connectors. And eventually there also is the option of a Bluetooth connection - if your PC has such a device.

In the end I personally heard no major difference between analog and digital signal handling. Neither with USB nor the optical connection to my old ASUS Xonar D2X sound card or the optical connection to the X-FI Titanium nor the onboard GM206 High Definition soundcard. The TI-Burr-Brown DAC of the Asus card still seems to be relatively good - at least for my ears.

I also have an additional X-FI Titanium card from Creative in my PC. I like the sound of the Asus card better with my Sennheiser headphones. Regarding the Nupro X3000 I was actually in doubt: For some music I find the sound slightly crispier with the X-Fi. However, whether this is a sign of quality is questionable. I change the sound card from time to time, just for fun - and still have no real preference.

Regarding distances the analog cable option for the connection to your PC's sound card may be the most reasonable solution - as the optical, SPDIF coax and USB cables coming with the speakers are of limited length.

There is even a possibility to realize a pure Wifi connection from your PC to the X3000 RC speakers. Such a solution, however, requires a special transceiver (135 €) from the producer Nubert; see below. I have no tested this type of connection, yet.

They speakers offer you some basic options regarding the sound balance. A very positive feature is the integrated 5 band equalizer. As said above this allows for a basic adjustment of the sound signature. Not unimportant in my age. In addition the handheld remote control device allows for a change of the relative basic balance between bass and treble.

You can also define a lower cut-off frequency for the bass and the transition frequency to a sub-woofer. Furthermore you can set 6dB a gain of certain analog input channels.

Disappointments ?

Something which disappointed me was the Bluetooth connection of the X3000 RC to my old Samsung smartphone - here I got periodic dropouts. I have not clarified this problem up to now. I do not exclude problems with the Bluetooth and the VLC player on my phone. In reviews I have not read about any such dropouts - but you have been warned. I recently tried a Bluetooth connection from my laptop, too. This one worked flawless. So, I do not know ...

Another major disappointment was and is Nubert's "X-Remote App". In my case it simply does not work on my Android 6 device. It gets stopped by Android just after granting permission to determine the geo-location. Which by the way is something I do not like in general. I got in contact with the Nubert company recently. They affirmed that they do not collect data, but that it is Google which enforces the explicit accept for geo-location when building up Wifi connections. Had to be expected, we know this stupid problem already from the mess with the German Corona App on Android. BBG again - Big Brother Google ... No further comments required.

I had no real need for the App so far. After the basic setup of all the speaker's internal settings (e.g. the equalizer) I can control the most needed adjustments via the handheld remote control accompanying the speakers. The "room calibration" feature of the App would have been nice - but it requires buying an additional piece of microphone equipment from Nubert for Android smartphones.

Sound quality

Do not expect a solid sound quality review from me. I have neither equipment nor objective, trained ears for such a review. I can only describe an impression - very much in analogy to wine - a sort of personal sound "taste and feeling" after having heard a lot of music on the speakers. Do I like them with different kinds of music, vocals and instruments?

In a nightlong session I have also compared the Nupro X3000 capabilities with my old Elac 4π (4 Pi) speakers in the living room. They are controlled by NAD pre- and end-amplifiers plus a NAD CD player. I did the comparison with music pieces of very different styles. I really was astonished how good the the small Nupro 3000x speakers could follow the 4π (4 Pi) Elac speakers and fill the room with sound and a solid bass base! Well, of course the Elacs do a better job with the bass at some point, but no wonder regarding their dimensions. Still, this first impression of the Nupro speakers was very convincing.

Then I moved the Elacs and Nupros boxes into my smaller working room - well, the Nupro X3000 at once felt much more adequate. They positioned different sound origins in the stereo sound cloud much more precisely - which is no wonder either. And they filled the whole room with music easily.

A hint: As the speakers work with a bass reflex opening at their backside you should not position the boxes directly at at wall - but leave some space.

Meanwhile, I have listened to a broad spectrum of music on these speakers - ranging from Eberhard Weber, Jan Gabarek, Kjetil Bjørnstad (with an without vocals), Laurie Anderson to compositions of Steve Reich, Rihm, Arvo Pärt and to recent recordings of classical music as of the Danish String Quartet or Sol Gabetta. Intermixed with stuff from Riverside, Korn, Linkin Park, Amorphis, Insomnium, Dark Tranquility, In Flames and Rammstein. As well as a lot of classical symphony and opera recordings. And - as a very welcome side effect - I have re-detected the wonders in the songs of Tom Waits.

You know what: All of it was pure joy - taking into account the sometimes strange intentional distorted mix you find in some heavy metal pieces.

In my opinion the balance between bass, mid-range and treble of the X3000 RC speakers is very good. You (almost) never loose the resolution of instruments covering different frequency regions. Some critics in the audio press was directed to problems in the mid-range frequency area. Personally, I cannot confirm this. If there is some problem, I would bet it appears in larger rooms. But this is not the target environment of these speakers. In my working room the mid range appears very present - both with vocals and classical instruments. But, probably I do not know what high end sound really is ... 🙂

I could not hear any bass resonances so far - with standard settings. But when you place the speakers close to a wall or corner you may want to reduce the low bass (< 100 Hz) a bit.

Summary: I very seldom use my Sennheiser headphones these days. I really do like the sound of these speakers.

Are there weaknesses? Well, the X3000 speakers have a little weakness at very low volume in my opinion - the relative weight of mid-range vs. bass changes to bass. May have to do with reflections in the room (or my hearing). But the advantage is that I have so far not felt any need for setting the loudness option to on.

Future options?

Now, I come to a point which makes the Nupro boxes also an investment into some future wireless audio infrastructure: For 135€ you get the NuConnect trX Wireless transceiver ( This little brick allows eg. for multi-room wireless solutions, but also for a transmission of digital signals from your PC or other sources to the active speakers.

Alternatively, you could also think about a combination of the trX Transceiver with the "NuControl 2 pre-amplifier" or (a cheaper) AmpX amplifier - both interesting products of Nubert. The latter amplifier uses in my understanding the same amplifying bricks as the active speakers, but now combined and supplemented with other electronics and thus turned into a full amplifier. The critics of this 700 € amplifier are surprisingly good (see:

So, the speakers mark an entrance into a much broader eco-system. In my case a completely digitized audio center on a Linux workstation combined with the trX transceiver, the X3000 speakers, the AmpX and other already existing audio equipment in different rooms appears on the horizon.

Sound support on my Linux system

Working with two soundcards
As I have two sound cards available I kept the three front speakers and the subwoofer box of my old Creative speaker set. The front speakers are placed on my working table - the subwoofer on the floor. This allows for astonishing surround feelings even with stereo sound. A little contribution of these desktop speakers to the louder sound coming from the X3000 in the background and you "swim in an extended audio space". Interesting for some kinds of music. Here the Pulseaudio mixer (pavucontol) on a Linux system is of advantage to balance sound contributions between the different channels of the active sound cards accurately and al gusto.

Regarding the Linux sound support in general
As a Linux user I have made my peace with Pulseaudio, pavucontrol, the Ladspa equalizer and KDE's Phonon over the years. It is sometimes still a mess to reproduce working settings for multiple multi-channel sound cards after system upgrades - but once PA and Phonon do work as expected, they do their work well.

The last time when strange things happened was when I upgraded to Opensuse Leap 15.2. Reason: Substantial changes to the Phonon user interface combined with a loss of differentiated setting options. As a result I had to manipulate the directives in the PA configuration files locally in my home directory and below /etc/pulse to get everything right again. The loss or hiding of options is a sickness that has spread itself over central KDE applications during the last years .... I always make a backup of my personal PA settings in my home directory and central Alsa and PA settings, now.

A major topic always is to find working settings which direct all sound output of any application through the Ladspa equalizer and then its output to multiple sound cards. On a KDE desktop such settings have to be consistent with Phonon settings - or the system will forget and overwrite your preferences with the next system start. Then you know that you have to manually change entries in the configuration files ...

Be careful with your new speakers when experimenting and switching to new sound configurations - e.g. from analog to digital signals or changes of the the sound card or moving from PA to pure Alsa. The resulting sound and, in some cases, also distortions may be louder than you expect! Always turn the volume of your external speakers to a minimum ahead of such experiments - and also reduce the volume of sound sources to a very low level.

During the last three to four years I have used the PA mixer "pavucontrol" to control the relative volumes of sound sources (i.e. applications) and the audio channels of the different sound cards on my system. But be careful with your settings here, too. In the past Pulseaudio did some strange things with audio signals from the system - e.g. turning them suddenly to 100%. I have not experienced such things in the past 3 years, but Nupro X boxes are too expensive to risk any accidental damage.

The 15-band PA Ladspa equalizer helps to define some basic sound presets with very slight adjustments - the Nupro speakers basically do not need any significant changes from a flat frequency curve of the equalizer.

Note that changes of the equalizer's settings may be accompanied by a general volume reduction on pavucontrol and a loss of relative channel weights there. Saving (and loosing) presets of the equalizer is no fun either. Some mess will probably always remain with PA ... You just need to invest some time into balanced presets - and then do not touch the central equalizer again.

The good thing is that you can change the direction of the output of applications to a sound sink directly with pavucontrol. So, you can configure the sound output of music applications to run through an equalizer or not. Again - be careful with the impact of such changes on the volume.

My favorite player still is Clementine at 48.000 or 96.000 Hz sampling rate. It offers its own equalizer. If you want to fiddle with an equalizer than use this one.

Sound extraction from CD recordings I do with K3B to "lossless" Ogg Vorbis or Flac encoding.


The active Nupro X 3000 RC speakers are worth the money you have to pay for them. They suit any Linux workstation well. The connection options to sound sources are manifold. Basic analog cable connections work, of course. An USB connection was directly supported on my Opensuse Linux. Optical and SPDIF coax connections to respective output connectors of sound cards work well, too. The possibility to create a full Wifi based solution with some extra (135€) equipment from Nubert is an additional goody.

The setup and the configuration of a speaker pair were very simple. You get an included 5 band equalizer in each speaker, which allows for basic room and position adjustment.

The general sound quality is in my opinion and for my ears excellent. The speakers easily fill small and even rooms up to 40 square meters with sound and provide a solid bass. The balance between bass, mid range and treble fits my ears. Single instruments in complicated arrangements are well distinguished. The positioning of sources in the stereo range is very good.

Links article/ audio/ lautsprecher/2087-test-aktive-kompaktbox-nubert-nupro-x-3000-rc/1.htm

Enforcing specific command arguments for a selected user with sudo

In one of my last articles I needed to enforce the execution of a command with certain arguments - specific for the present user. I.e., I wanted to take away the freedom of the user to set arbitrary command argument(s) as he/she liked.

This had to be done in addition to another set of rules - namely a bunch of iptables filter rules which also depended on the UID. So the command had to be run with the UID of the user him/herself and not with the UID of root.

The solution came with sudo. This may appear a bit surprising to some readers. The reason is that sudo normally is used to allow selected users to run commands with another UID than the one they have themselves. I call "the other user" the "effective user" below. In a sudo context the effective user corresponds to a SUDO_UID variable in addition to the UID environment variable. The predominant example for invoking the sudo-mechanism certainly is to allow users to run a command as root. But it can be extended to any other user (made harmless by taking away hsi/her login shell or being especially privileged due to membership in a special group).

In my case I needed to enforce command execution with an effective user being identical to the original user him/herself - but with special arguments. In such a situation you have to take take the permission to execute/read the original command completely away from the user. Otherwise he/she could use it with any argument. But sudo requires that the defined effective user is able to read and execute the command. This seemingly contradictory situation can be solved by invoking a special user-group.

Maybe the recipe described below helps some readers to enforce command execution with specific arguments in other contexts.

A simple scenario

Let us assume you have developed a program "myprog" which accesses special web-service that you have installed on some web-servers in your Intranet. Let us further assume that some specific users shall be restricted to access the service on a defined server only - and there only with certain arguments. Such parameters may reduce or give rights to access certain data the service could in principle provide. All this is regulated by 2 arguments to the myprog-program: a FQDN for the host and a "level". "level 0" allows free access to a very basic service version. "level 1" invokes the program with personalized options and requires a login. But your people have started to play around with the Login. So, you want a group of users to issue the command with a certain "host" and "level 0" only. Let us assume that user "mark" is one of those users who should invoke the command only in the form

mark@mytux:~>myprog -h -L 0

How can we achieve this with sudo?

Restricting command use to specific arguments

Below I discuss modifications of the "/etc/sudoer" file. This is risky in very many ways - not only regarding security.

Disclaimer: I take no responsibility whatever for the consequences of the sudo approach described below and its application to your computers. The sudoer rules have to be tested carefully before the are used in a production environment and their setup must be supervised by an expert.

I assume that you have installed your program at the path "/usr/bin/myprog" with standard rights

-rwxr-xr-x 1 root root 334336 17. Mai 2020  /usr/bin/myprog

Then one can follow the following recipe (as root) to get "mark" under control:

  • Step 1: Create a special group for the command in question, e.g. "mygroup". Ensure that mark does not become a member of this group.
  • Step 2: Change the ownership and access rights of "/usr/bin/myprog" according to
    • chown root.mygroup /usr/bin/myprog
    • chmod 750 /usr/bin/myprog
  • Step 3: Add some lines to "/etc/sudoers" (with visudo):
    Defaults env_reset
    Defaults:mark env_keep += "DISPLAY"
    #Defaults targetpw   # ask for the password of the effective target user e.g. root
    #ALL   ALL=(ALL) ALL
    mark ALL=(mark:mygroup) /usr/bin/myprog -h -L 0

Due to step 2 user "mark" cannot read, change or execute the command directly any longer. The rest depends a bit on ensuring the "mark" never becomes a member of group "mygroup". (But other users which you trust may become members.)

Regarding the sudoer rules I assumed that you reset the environment of a sudo user as a default. Keeping up the "DISPLAY" variable helps to get around some access problems with the present X11-screen of "mark". I also assumed that you use the sudo-mechanism in a way which requests that the user enters his/her password. The last line allows "mark" on all hosts/terminals to execute "/usr/bin/myprog" as him/herself, but with the GID of group "mygroup" and exactly with the options "-h -L 0".

Note that sudo compares the command including arguments as one string!

User "mark" must run the command myprog from now on in the form:

sudo -u mark -g mygroup  myprog -h -L 0

and enter his password. Any deviation will be blocked by the sudoer mechanism.

Some practical hints

After carefully evaluating security implications you can make life easier for "mark" in two ways:

  • Let him execute the command (with the defined arguments) without providing a password. Use the NOPASSWD attribute; see the man pages for the sudoers file.
  • Write a script which encapsulates the described sudo command with the options.

By such measures, you may save "mark" some typing time.

Another point is to keep the file permissions up in the future. This may become a problem if and when you apply the described mechanism to some standard Linux commands which are installed and updated by some package administration tool of your distribution. You have to carefully check that the installation routines do not overwrite the permission settings! A handwritten systemd service or a cron job may help you with this task.

With some reading or experience it should be easy to extend the described recipe to groups of users and to other commands.

There are multiple ways to allow other users to execute the command freely if this should be required. The sudoer file knows about a logical NOT operator (!); this helps to add a sudoer rule for all users but NOT "mark". Another simple approach would be to add all users but "mark" to the group "mygroup".


The sudoer-mechanism is a mighty Linux tool. We can not only allow users to execute commands as another user, but also with the permissions of another group. AND we can enforce the usage of commands with predefined arguments for selected users or user groups.

As fiddling with the sudoer mechanism is always a bit risky: Please, write me a mail if you find some major mistake or security problem of my approach.

KVM/Qemu VMs with a multi-screen Spice console – VIII – VM and user specific restrictions for remote-viewer connections – iptables and sudo

The Spice console allows users to access the graphical desktop of a Qemu based virtual machines [VM]. The performance with both data encryption and data compression is excellent, audio is no problem and the required data transfer rates to client-applications as "remote-viewer" are within reasonable limits for a (switched) LAN. In virtualization scenarios where you can organize tasks according to a scheme "one user per VM" Spice is actually an attractive tool - and even professional virtualization environments a "Proxmoxx" and "oVirt" make use of it.

In this series we look at basic setups in self-administered Intranet environments. So far we had some ups and downs regarding the tool remote-viewer. If you want to use it in a desktop virtualization environment it is an almost perfect tool. We also found it to be a very convenient and efficient remote client-tool in an Intranet when we combined it with SSH and internal data compression of the Spice protocol. See:

KVM/Qemu VMs with a multi-screen Spice console – V – remote access via remote-viewer, a network port and a SSH-tunnel
KVM/Qemu VMs with a multi-screen Spice console – IV – remote access via SSH, remote-viewer and a Unix socket
KVM/Qemu VMs with a multi-screen Spice console – III – local access with remote-viewer via a Unix socket

SSH gave us all options we needed to take care of various security issues in remote access scenarios. The KVM/Qemu server could control the interaction of remote-users with VMs by applying user-specific SSH restrictions to port-forwarding. We could establish rules to bind the Spice access to a specific VM to a specific user.

Regarding the last point the combination of remote-viewer, TLS and SASL came as a solid disappointment. TLS worked perfectly. But we had problems with SASL; see:

KVM/Qemu VMs with a multi-screen Spice console – VII – remote-viewer, qemu and SASL authentication
KVM/Qemu VMs with a multi-screen Spice console – VI – remote access with remote-viewer and TLS encryption

We got SASL authentication working in two different ways. The frustrating result of our efforts, however, was that we could not confine the access to the Spice-console of a specific VM to exactly one user.

In the end we found that it might even be better to use TLS and a VM-specific Spice password set in the VM's XML-domain file. The problem then still is that users could share the password for a specific VM. So, we still could not ensure a scenario "one VM - one UID, only".

In this article we, therefore, look at measures on remote client-systems to allow a TLS connection to a specific VM on the KVM/Qemu host for exactly one user. We use two different Linux tools - namely iptables and sudo - to achieve this. The recipes given below are interesting in themselves and can be applied to other scenarios where the admin wants to restrict outgoing TCP-connection on a user specific level.

Why do we care about user-specific control for Spice at all?

Assume a situation in a small Linux oriented office where you run a bunch of VMs for special purposes on a central KVM-server.
You provide e.g. a VM (VM1) with Windows 10 ( 🙁 ) for book-keeping with a program your tax advisor understands. A user "Charlie" with a defined UID should use the VM's Spice console, but basically only he (and his boss in the evening hours).
You have a second VM (VM2) with a Web-server for development and test purposes. Only user "Maggie" shall have access to the Spice console of VM2 on Mondays and Tuesdays and a user "Anne" on Wednesdays and Thursdays and no one else.
And then there is yet another VM (VM3) which only user "Ralph" shall access via Spice to create documents of a confidential analysis for a governmental organization.
There are multiple Linux client PCs available in the office; any of the user can use and login to any free Linux workstations. None of the user has root rights on the clients and the server.

We have thus defined a scenario of the type

One VM + Spice console    < = >    one user or a group of selected users.

Can you cover such a situation with remote-viewer, TLS and server-based SASL, only?
The answer of my last article was: NO. At least not by simple means. (By the way: It is not the fault of SASL. Remote-viewer, simply and unfortunately, does not provide any system-based data for the realm or for the remote-system which SASL could evaluate. The user has too much freedom ...)

Do we need measures on the client-systems?

It is interesting that even Opensuse's "Virtualization Guide" writes about some required measures on the client (restricting access to specific client-certificates for selected users) when discussing the security for libvirt and vnc as tools to access the graphical desktop of a VM. We have not come to libvirt-based tools in this series, yet, but this is already some indication that restrictions of desktop access to KVM/Qemu based VMs may sometimes require measures on the client. So, let us turn to the client-systems ... Of course, we assume that such clients have a Linux OS, in my case a Opensuse Leap 15.2.

Schematic drawing

The following schematic drawing reflects the situation we want to control:
We want to make it impossible user "mybro" to access the Spice console of a VM1. Only "myself" should be able to use VM1's Spice console via a TLS connection. The other way round: Only user "mybro" shall be allowed to connect to the the Spice console of VM2 with remote-viewer. Cross-connections are forbidden; each user gets access to one defined VM only.

We use the same systems as in the last articles: A KVM/Qemu server host "MySRV" (IP: with a Leap 15.2 OS on it, a test-VM1 "debianx" with a Kali-OS on it and a client-system "MyLAP" (a laptop with a Leap 15.2 OS; IP: On MyLap we have a user "myself" and a user "mybro". VM1 ("debianx") gets the (TLS-) port 20002 on the server, and VM2 ("leaptest") the (TLS-) port 20004.

We shall perform the experiments in this article with a Qemu set up without SASL, but each VM configured for an individual password. (As we already know it will only means a small difference in the form of the authentication dialog. We will not be asked for a username.) The scenario can easily be changed to SASL authentication.

Strategies to allow Spice access to a VM's desktop only for a specific user

There are three major strategies we can follow:

Strategy 1: We could think about a specific TLS client certificate for a connection to a VM and to make it accessible only to the user in question. Such a strategy would require that client certificates are supported by Qemu and Spice.

Strategy 2: We could use iptables and add user-specific rules for outgoing data to certain TLS-ports on the server. As user-related rules can only be set for the "output chain" we cannot set any such user-specific filters for our problem on the server.

Strategy 3: We take the choice of the target port on the server away from the user as well as any free access to the remote-viewer command namely by changing file permissions, setting up special sudo rules and/or enforcing him/her to run a shell script which starts remote-viewer with a pre-defined target port for him/her.

The strategies (if working) can be combined. Even if the firewall of strategy 2 failed the user would only get access to a specific VM by restrictions of strategy 3. But all these things are a bit complicated and they all depend on the user not being able to get root rights, the firewall being set up at every system-startup and the sudo rules being tight. This is crucial; our KVM/Qemu server with TLS and SASL could only block connections from certain IPs, but not really users.

We could extend strategy 3 to a network namespace - but it won't help too much as we then would again need to apply routing and related firewall rules. Or to sudo rules. We could also think about using different networks for different VMs and thus a port-IP-VM-relation - but we would still depend on user-specific firewall rules on the clients.

Strategy 1: What about Spice and TLS client certificates?

Here I come with bad news:
If you activate the option "default_tls_x509_verify = 1" in "/etc/livirt/qemu.conf" it is simply ignored. One can guess it from a lack of required parameters in the qemu-command created by virt-manager. Even if and when you provide client certificates in the required directories on the server and the client. In contrast to VNC-settings there is no option like "spice_tls_x509_verify = 1" available. If you set it by yourself, it is silently ignored.

So, client-certificates will be of no help with Spice and remote-viewer. The situation my be different for the libvirt-dependent "virt-viewer" tool. But this is the topic of a future blog post.

Strategy 2: netfilter/iptables to the rescue

I assume that you have some tool in place on your Linux systems to configure your own iptables-rules. Professionals may write their own scripts. Independent of your interface to netfilter/iptables, it is obvious that working with firewall rules in a productive environment is a risky business. Therefore:

Disclaimer: I take no responsibility whatever for the consequences of the approach describes below and its application to your computers. The iptables-rules have to be tested carefully before making them productive and their setup on Linux hosts must be supervised by an expert.

In my network environments I still cling to the tool "fwbuilder" because it gives you a good graphical overview for most purposes and it allows for more complex configurations than e.g. frontends to firewalld or ufw. So, let me show you how to set up a basic set of user-specific iptables rules with fwbuilder and then have a closer look at the contents of the created statements of the firewall script.

fwbuilder allows you to set up "users" with a defined UID in the object catalog for "services":

This may seem strange; but the meaning is the following:

  1. Using a "user" as a "service" will trigger the creation of a rule for the OUTPUT chain which matches the user of outgoing connection packets against an owner with a defined UID and then triggers a reaction.
  2. To cover the reaction in fwbuilder we "branch off" into a specific rule-set for the user. On the iptables level this corresponds to a user-defined rule-chain as a reaction target.
  3. The filter-rules for data packets in the user-defined chain themselves then lead to certain final reactions in the sense of "allow" or "deny".

In pseudo-code: IF a user matches an UID THEN apply a set of filter rules with their own final reactions.

In Fwbuilder a set of filter-rules is usually put into an object called "policy". The following image shows some rules of the main "policy" on "MyLap":

You see that rules 4 and 5 include users "myself" and "mybro"; the rules branch off to policies "Spice_VM_1" and "Spice_VM_2", respectively.

Rule 6 blocks a whole bunch of TCP-ports used for VMs on the KVM/Qemu server for any other user than "myself" and "mybro".

Policy "Spice_VM_1" contains one rule, only:

This rule specifies a certain interface and the IP of the target host "mysrv". We allow access to port 20002 - corresponding to the TLS port defined for our test VM "debianx" (VM1). Something analogous holds for our second user "mybro". He gets access to another virtual machine "VM2" which we have bound to port 20004 on the KVM-server for external TLS connections.

Now, let us look at the iptables statements generated by fwbuilder:

    # ================ Table 'filter', automatic rules
    # accept established sessions
    # backup ssh access from a admin host 
    $IPTABLES -A INPUT  -p tcp -m tcp  -s  --dport 22  -m state --state NEW,ESTABLISHED -j  ACCEPT 
    $IPTABLES -A OUTPUT  -p tcp -m tcp  -d  --sport 22  -m state --state ESTABLISHED,RELATED -j ACCEPT

    # ================ Table 'filter', rule set Spice_VM_1
    # Rule Spice_VM_1 0 (eth0)
    echo "Rule Spice_VM_1 0 (eth0)"
    $IPTABLES -N Spice_VM_1
    $IPTABLES -N Cid40091X30615.0
    $IPTABLES -A Spice_VM_1 -o eth0  -p tcp -m tcp  -d   --dport 20002  -m state --state NEW  -j Cid40091X30615.0
    $IPTABLES -A Cid40091X30615.0  -s   -j ACCEPT
    $IPTABLES -A Cid40091X30615.0  -s   -j ACCEPT
    # ================ Table 'filter', rule set Spice_VM_2
    # Rule Spice_VM_2 0 (eth0)
    echo "Rule Spice_VM_2 0 (eth0)"
    $IPTABLES -N Spice_VM_2
    $IPTABLES -N Cid40661X30615.0
    $IPTABLES -A Spice_VM_2 -o eth0  -p tcp -m tcp  -d   --dport 20004  -m state --state NEW  -j Cid40661X30615.0
    $IPTABLES -A Cid40661X30615.0  -s   -j ACCEPT
    $IPTABLES -A Cid40661X30615.0  -s   -j ACCEPT
    # ================ Table 'filter', rule set Main_Policy
    # Rule Main_Policy 0 (eth0)
    echo "Rule Main_Policy 0 (eth0)"
    # Antispoofing
    $IPTABLES -N In_Main_Policy_0
    $IPTABLES -A INPUT -i eth0   -s   -j In_Main_Policy_0
    $IPTABLES -A INPUT -i eth0   -s   -j In_Main_Policy_0
    $IPTABLES -A FORWARD -i eth0   -s   -j In_Main_Policy_0
    $IPTABLES -A FORWARD -i eth0   -s   -j In_Main_Policy_0
    $IPTABLES -A In_Main_Policy_0  -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
    $IPTABLES -A In_Main_Policy_0  -j DROP
    # Rule Main_Policy 1 (lo)
    echo "Rule Main_Policy 1 (lo)"
    $IPTABLES -A INPUT -i lo   -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -o lo   -m state --state NEW  -j ACCEPT
    # Rule Main_Policy 2 (global)
    echo "Rule Main_Policy 2 (global)"
    #  ICMP, DNS, DHCP 
    $IPTABLES -A OUTPUT -p icmp  -m icmp  --icmp-type 3  -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp  -m icmp  --icmp-type 0/0   -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp  -m icmp  --icmp-type 8/0   -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp  -m icmp  --icmp-type 11/0   -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp  -m icmp  --icmp-type 11/1   -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp -m tcp  --dport 53  -m state --state NEW  -j ACCEPT
    $IPTABLES -A OUTPUT -p udp -m udp  -m multiport  --dports 68,67,53  -m state --state NEW  -j ACCEPT
    # Rule Main_Policy 3 (global)
    echo "Rule Main_Policy 3 (global)"
    $IPTABLES -A OUTPUT -p udp -m udp  --dport 123  -m state --state NEW  -j ACCEPT
    # Rule Main_Policy 4 (global)
    echo "Rule Main_Policy 4 (global)"
    $IPTABLES -A OUTPUT -m owner --uid-owner 1021  -j Spice_VM_1
    # Rule Main_Policy 5 (global)
    echo "Rule Main_Policy 5 (global)"
    $IPTABLES -A OUTPUT -m owner --uid-owner 1022  -j Spice_VM_2
    # Rule Main_Policy 6 (global)
    echo "Rule Main_Policy 6 (global)"
    $IPTABLES -N Out_Main_Policy_6
    $IPTABLES -A OUTPUT -p tcp -m tcp  --dport 20001:20010  -j Out_Main_Policy_6
    $IPTABLES -A Out_Main_Policy_6  -j LOG  --log-level info --log-prefix "RULE 6 -- DENY "
    $IPTABLES -A Out_Main_Policy_6  -j DROP

These are simple rules which the experienced reader will have no difficulty to interpret. (The reader also sees that I have multiple IPs on eth0, but this does not affect our present topic).

I leave the test to you. You should see that user "myself" can access VM1 (debianx) whilst user "mybro" and any other users cannot. User "mybro" instead can access VM2 on the server.

Important note:

Do not forget to write a small systemd service which starts your firewall automatically during the startup of your client-system.

I have written about his topic somewhere else in this blog already. believe me its easy.

Strategy 3: Using sudo

Working with "sudo" and manipulating the file "/etc/sudoers" is somewhat risky. Therefore:

Disclaimer: I take no responsibility whatever for the consequences of the sudo approach describe below and its application to your computers. The sudoer rules have to be tested carefully before the are used in a production environment and their setup must be supervised by an expert.

The settings below work for an Opensuse Leap system - partially due to the default settings there.

A standard problem with sudoer rules for graphical applications is the handling of the access to the X11 display if you need to start programs as another user (e.g. root). (Things may be even worse with Wayland; but I have no experience with it). To keep things simple it is a worthwhile investment to think a bit about the precise nature of your sudo-objective.

In our case we want enforce a user-specific usage of the command remote-viewer. More precisely:

  1. We want to disallow the usage of remote-viewer for most users. And even selected users shall not be able to call or invoke remote-viewer directly and freely.
  2. We want to enforce user-specific arguments to the command "remote-viewer", if executed by certain selected users.
  3. If possible we do not want to run any remote-tool with root-rights at all.
  4. We want to keep our user-specific firewall rules in place and not to create new ones.
  5. X11-display access shall be possible.

The answer to this challenge is a bit tricky. It first looks like you need to write a separate script (accessible to root) which evaluates UIDs or SUD_UIDs and then calls remote-viewer with appropriate arguments.

But you will then be confronted with problems to access the X11-display of the user issuing the script. In addition rule 3 above forces you to start the required remote-viewer command in the end as a specific user via "sudo -u USER" or "su -c '...' USER". This in turn forces you to allow "USER" to execute the remote-viewer command anyway according to a specific sudo (!) rule for USER. Therefore, he/she must be able to read and execute the remote-viewer command. But then he/she could execute it outside freely without sudo - and again use any arguments he/she likes. It took me a while to find a way out.

The right approach is to find a rule working for the user in question, first, before you turn to a script as a mediator. On the other side: The user must NOT be allowed to use "remote-viewer" freely - neither by user or group access rights. This seeming contradiction is solved by the following steps on our client-system; we describe the rules below for user "myself". You must execute most of the commands as root:

  • Step 1: Create a special group, e.g. named "spicegrp". Do NOT make user "myself" a member of this group!
  • Step 2: Change the ownership and access rights of "/usr/bin/remote-viewer" according to
    • chown root.spicegrp /usr/bin/remote-viewer
    • chmod 750 /usr/bin/remote-viewer
  • Step 3: Check that remote-viewer can no longer be executed by user "myself".
  • Step 4: Start editing the file "/etc/sudoers" with visudo.
  • Step 5: Add the following lines and turn some existing lines into comments:
    Defaults env_reset
    Defaults:myself env_keep += "DISPLAY"
    #Defaults targetpw   # ask for the password of the target user i.e. root
    #ALL   ALL=(ALL) ALL
    myself ALL=(myself:spicegrp) /usr/bin/remote-viewer -- spice\://
    # myself ALL=(myself:spicegrp) NOPASSWD: /usr/bin/remote-viewer -- spice\://
    # mybro ALL=(mybro:spicegrp) NOPASSWD: /usr/bin/remote-viewer -- spice\://

This is all we basically need for the user myself. An extension to user "mybro" should be clear. See the commented line for mybro.

The sudoer statements - also the commented ones - deserve some short explanation:
We reset the environment, but we keep some language settings for sudoer users. More important: We keep the "DISPLAY" variable of the environment of sudoer user "myself". Meaning, it will be available when commands are executed with his/her UID. Hereby, we avoid major X11 trouble. The two commented lines in the middle correspond to the the objective that sudoer users should provide their own passwords instead of the root password to execute the commands in the prescribed form.

And then comes some sudo vodoo:

We only define a rule for the user "myself": We allow him/her to execute the command remote-viewer with his own UID, but with a different group. This gives him access to "/usr/bin/remote-viewer" under "sudo" conditions ( only !). But, in no way else on a shell's command line, as he/her no longer has access rights to "/usr/bin/remote-viewer" and is no member of "spicegrp"!

The other part of the magic is that the sudoer-mechanism checks the precise form by which the user in question (here: myself) executes the command. It compares the command exactly to the form given in the rule line including the command's arguments!

myself ALL=(myself:spicegrp) /usr/bin/remote-viewer -- spice\://

The command and the arguments to it are together handled as one string for comparison!
Thus we have a user "myself" who can only use remote-viewer with "sudo" and he/she is forced to provide a specific argument. And when he issues the command the firewall rules defined in the first part of this post should open doors to the VM as the execution is done with his/her UID!

What will the required sudo command for a successful access to the VM1 (debianx) at TLS-port 20002 on server MySRV look like:

sudo -u myself -g spicegrp remote-viewer -- spice://

You took notice of the argument for the group?

Test for a sudoer user

Let us test our theory (sorry for the German system messages, tried to translate them):

myself@mylap:~> remote-viewer -- spice://
-bash: /usr/bin/remote-viewer: Keine Berechtigung
myself@mylap:~> # Keine Berechtigung = No access right
myself@mylap:~> # Now with sudo - but wrong port 20004
myself@mylap:~> sudo -u myself -g spicegrp remote-viewer -- spice://
[sudo] Passwort für myself: 
Leider darf der Benutzer myself »/usr/bin/remote-viewer -- spice://« als myself:spicegrp auf nicht ausführen.
myself@mylap:~> # Translation: Sorry, but user myself is not allowed to execute »/usr/bin/remote-viewer -- spice://« as myself:spicegrp on
myself@mylap:~> # Now with sudo - but the right port 20002
myself@mylap:~> sudo -u myself -g spicegrp remote-viewer -- spice://

And now we get the familiar dialog to authenticate :

Our firewall obviously has let us through. And - after filling in the VM-specific password (we work without SASL here; see above), we get:

I leave it to the reader extend the whole thing to two users and to test all combinations out.

Making things a bit easier for the users

An authorized user has to type a lot of things to make the sudo command work. One thing, you can think about, is to not require a password for the sudo command. (Personally, I would not do this; a password is a last security barrier in case of configuration mistakes. But, in principle it is possible to work without a password in this specific case - after you have checked out and tested all security implications). The entry in the "/etc/sudoers" file then would look like

myself ALL=(myself:spicegrp) NOPASSWD: /usr/bin/remote-viewer -- spice\://

Another reduction of typing work comes through a script which readers can read and execute, but not change. The script could make all the relevant decisions for a user. A very simplified version would in my test scenario contain statements like:

if  test $SUDO_UID
        if test  $UID -ne $SUDO_UID
                echo "error - you are not allowed to run this command as another user"
if  test $UID -eq $Myself_UID
        echo "Hello Ralph"
        msg="You are entering the Spice console of VM \"debianx\" - happy working"
        echo $msg
        sudo -u "#$UID" -g spicegrp /usr/bin/remote-viewer -- spice://$host?tls-port=$myself_port
elif  test $UID -eq $Mybro_UID
        echo "Hello Brother"
        msg4="You are entering the Spice console of VM \"leaptest\" - happy working"
        echo $msg4
        sudo -u "#$UID" -g spicegrp /usr/bin/remote-viewer -- spice://$host?tls-port=$mybro_port
        echo "Sorry, you are not allowed to access VMs"

Note that the script would ask for a password before executing the sudo statement enclosed - if you had defined a password request in the sudoer file.
If you absolutely wanted to obfuscate the information contained in this script you could again use the trick with sudo and the special group spicegrp. You would the add lines

myself ALL=(myself:spicegrp) /usr/bin/rviewer
myself ALL=(mybro:spicegrp) /usr/bin/rviewer

to the "/etc/sudoers"-file

Important note:

You must not forget to check the fie permission of the file "/usr/bin/remote-viewer" after SW-updates or upgrades of your system.

I would recommend to start a small scheduled job or a service to check the rights settings frequently.


Remote-viewer connections to VMs cannot be controlled on a user level by the KVM/Qemu server if we just used TLS and SASL. We can set up a VM specific password. But external connections to a VM specific TLS port can only be blocked for external systems and IPs on the server.
However, on Linux client-systems iptables helps us to allow access to the Spice console of a specific VM for a selected user, only. This can be achieved by setting up user specific iptables rules on client-systems. This post has shown you how to create such rules for the OUTPUT chain with fwbuilder. We must set up a systemd service to implement these rules automatically at system (and network) startup.

To restrict users on Linux client systems even more we applied the sudo mechanism in a very specific way: we enforced the usage of certain arguments to the remote-viewer command for specific users. I think the method I discussed is safe; if you find a caveat please send me a mail.

Both strategies can and should be applied in Intranets where we want to provide remote-viewer and the Spice consoles of Qemu VMs as real working instruments.