Request classic confinement for glpi-agent

store-requests
1

Hello,

I just register my first snap with “glpi-agent” name. There’s no snap at the moment, but before going on, I’m requesting the classic confinement. GLPI Agent is an perl agent running essentially inventory tasks on the behalf of a GLPI server. This agent is based on fusioninventory-agent. It is pure opensource software (GPLv2).

It needs classic confinement as it needs to run well-known commands like “rpm” on a redhat based system to inventory softwares, or “dpkg” on debian/ubuntu one. It also needs to access system mount points definition to report volumn as if it was run natively. Many other standard command can also be run as requested to obtain the best possible inventory.

I still prepared a working snapcraft.yaml and it will be integrated in github soon. I decided today to include a full perl 5.32.0 build in the snap as I failed to use core20 or core18 one in a safe way.

2

Hello,

our github repo is now including a snapcraft.yaml and I setup the automatic build from snapcraft.io. It seems only amd64 & arm64 are working for this snap but they of course were rejected for publishing as classic confinement has not been granted.

I received and alert telling I have to request the classic confinement. It is here, so did I miss something ?

Thank you

3

Hey @g-bougard,

You did not miss something, this is the right place to move fw with your request.

If you take a look at our Process for reviewing classic confinement snaps, the need to launch arbitrary applications is not generally considered a supported use-case for classic confinement. Have you explore the possibility of shipping the tools you need (e.g. stage-package) in your snap?

You could also try the mount-observe interface and in this way keep your snap strictly confined, enjoying all the benefits of a stable runtime environment. Please remember that classic snaps run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions.

4

Hello @emitorino

to answer your first question, yes I still explored that possibility, and indeed I still embedded dmidecode (with try; directive as not supported on few arch), usbutils, pciutils and hdparm. These commands are the most basic of the useful ones and we recommend they are installed on computers when the agent is run natively. But we can’t really embed all needed command as:

  • the principle of the agent is to run many dedicated modules on conditions, and many conditions are defined by checking a command is runable, as example, we does snap software inventory on the condition the snap command is runable…
  • the idea is anyway to create an inventory with what is available on the computer, not with what we can install ourself (even if few commands like dmidecode can help a lot, so they are recommended)
  • some of the command the agent could start are simply proprietary (I think for example all the commands used to parse hardware drive array setups, like tw_cli for 3ware RAID arrays)
  • this would make the snap larger and larger and this is not suitable in most usage.

The agent still needs to be run as root to be able to produce the best inventory as many used commands still have security issues if they are used to write things or modify the system. In our PR review process, we only accept command options that make them only affect the output without modifying the system. Indeed, one goal of the agent is really to safely use dangerous commands… and the strict confinement makes most of them unusable or simply not runable/seen.

I firstly tried to use strict confinement for the snap and I still didn’t find the right way to access all what we need to produce the same inventory as if the agent was run natively. The first major issues I found on my own computer (fedora 33) was the computer was reported as running on ubuntu and the software inventory simply failed as rpm is not runable.

About using mount-observe, I still tried it and even with others as I used:

    plugs: [hardware-observe, system-observe, network-observe, mount-observe, kvm, system-files]

But I didn’t obtain the expected result as explain earlier. I also though to rebase our command search other the snap internally mounted filesystem showing original filesystem but I read somewhere this should be avoided as the mount point is not in the snap specs. I guess this can be used for debug or diagnostic purpose only and we have no guaranty the mount point will not change in the future.

About interfaces like mount-observe, I must admit I’m definitively frustrated as the documentation is so light. I would expect for such important feature a full description of what it provides/permit. And at worst, I would expect a link toward the implementation in source so a dev like me can read the source as documentation (and eventually contribute the doc back for more lazy people :wink:).

About taking care of the snap working reliably across distributions, I think our context is an exception:

  • we uses perl which is portable other targeted platforms as a logic layer and to secure requested command runs,
  • we makes a real effort to protect our users from any abuse even if no body is perfect and so mistakes are still possible.

And to conclude, having glpi-agent in snap store is finally not a major goal for us as we still can provide native rpm & deb packages for major distros (including Ubuntu :wink: ). This would simply be handy to have it in store as it would be a way for some people to obtain quick updates or be able to try development releases or hotfixs. Snap store is really a nice facility.

Sorry for this long comment but I like to be as clear as possible and I apologize if my english is not finally as this is not my primary language. I’m still a new snap enthusiast user :slight_smile:

5

For glpi-agent to run successfully it would appear to need to collect information about the system. There are a number of existing interfaces like system-backup which allow read-only access to the entire host filesystem etc. You could then look in /var/lib/snapd/hostfs/usr/bin etc to enumerate all the binaries on the host etc.

As far as executing/running binaries from the host is concerned, this is not possible under strict confinement, and is itself not a supported use-case for classic confinement. However, as @emitorino mentioned, you can easily ship the required binaries like rpm or dpkg etc within the glpi-agent snap itself and you can execute them from there. This also means that you don’t have to cope with different output from different versions of these binaries on various systems etc since there will only be the exact one which your snap ships which should make things easier.

Finally, instead of system-backup you could also use the system-files interface to request access to just particular files within the host system as well so that these binaries can do their job if that is an easier path.

As such, whilst it may be a bit more work to get it all together, it would appear that glpi-agent should be able to run as a strictly confined snap.

6

Hi @alexmurray

thank you for your answer.

I understand how I can use system-backup to access the entire host filesystem in read-only. This would be perfect for some inventory features, but not for all. Honestly I didn’t go through this interface as it’s description is “read-only access to the system for backups” in the supported interface listing. An inventory agent is not a backup software so I missed this interface and even I though you would have refuse such misuse. After that this may need me to adapt the agent to support the snap confinement context, but this is still possible, even if this is not desirable.

As far as executing/running binaries from the host is concerned, this is not possible under strict confinement, and is itself not a supported use-case for classic confinement.

Not supported use-case for classic confinement, do you mean for SnapStore integration ? Indeed ? I read in the criteria section of classic confinement requirement process: “running arbitrary command” could be a requirement. So why not “preconfigured commands” ?

And as I still explained, shipping the binaries is not a solution as the binary availability is still a way to make dedicated inventory. The agent can’t assume what is installed this is definitively not the goal of inventory. Also, the agent can’t even more presume what command version is installed. Just to take the rpm command case, at some time, the local rpm database may have a format upgrade and becomes unreadable by an old version. This is a good reason to run the host command, not the one we shipped in the snap.

This is probably a stupid question, but would it be possible to chroot a host command under /var/lib/snapd/hostfs in a strict confinement ? In my point of view, accessing the host filesystem in read-only should be sufficient for the agent purpose but I can’t understand execution is just forbidden by the apparmor context. Or maybe making a “backup” of the command if seen (with all its binary lib deps) into a temporary snap environment can do the trick… But I guess this would be another ugly hack :sweat_smile:

7

No it is not possible to exec from hostfs under strict confinement (even if you could chroot to hostfs - which you can only do as root) - as the default AppArmor policy denies access to /var/lib/snapd/hostfs and even with system-backup this only grants read access to hostfs, not execute - so you can’t execute any of the binaries there.

I still feel that if glpi-agent only has a preconfigured list of commands that it makes a lot of sense to ship these with the snap. I realise that given the way glpi-agent works currently that classic confinement makes the most sense, however as stated previously, we have strict guidelines on what are supported use-cases for classic confinement and it is not clear to me that glpi-agent fits within one of these.

8

Thank you, I didn’t test but I suspected what you explained. And finally, this is strictly what I would expect of a really good strict confinement. So this is definitively fine.

Indeed I still have defined a preconfigured list of commands shipped with the snap. But it is really short. Here it is: “dmidecode”, “hdparm”, “lspci” and “lsusb”. I felt nice with them as they can miss sometime for hardware inventory and they don’t rely on other locally installed files (IDS databases for lsusb & lspci are also shiipped). Maybe other hardware related command could be, but we still have all we need with these 4 commands.

My concern is more about software inventory and virtualization inventory. Here we really depends on what is installed on the host system. You didn’t answer, but maybe making the command and related libs “backup” into the snap environment for later execution could work. This is probably a huge work and I don’t know if I’ll have the time to dig that way. But this could be interesting and could finally make the agent definitively secure. This work could even become a snap tool for people with the same kind of issues. Or maybe snap should provide such a tool or do you know about such kind of tool ? For libraries I guess setting LD_LIBRARY_PATH to some paths in /var/lib/snapd/hostfs would not be sufficient.

To conclude, we understand the currently strict guidelines are probably not fitting the currently listed use-cases. Maybe the inventory case should just be added to that use-cases ? There’s a really huge potential of snap usage for you as actually glpi-agent is meant to replaced fusioninventory-agent in a near future and actually fusioninventory-agent is installed on undreds of thousands or even millions of computers :innocent: okay maybe only 20% of that number are linux but this is still big :wink:

9

Just another side note, the agent includes some tasks not directly related to inventory. There’s one which would become totally useless in a “strict” confinement. It’s name is “Deploy”. It is used by GLPI users to deploy softwares or files on the host. This task is mostly used on “win32” platforms so this may not be really a big deal: people needing this task won’t probably use a strictly confined agent.

10

Hey @g-bougard,

Thanks for your detailed explanation and feedback. To add a further note to what was already explained, when we talk about supported and unsupported categories, we mean software classification under which the given snap can be assigned and thus granted or not granted classic confinement. The process is revisited frequently and snapd improvements are identified accordingly. This is needed to achieve the purpose of snaps being a portable and secure mechanism for distributing applications. And snaps achieve this through confinement, access declarations and this rigorous review process. Please see security policy and sandboxing for further information.

Remember that otherwise, classic confinement snaps run without restrictions and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions. When possible, we try to help publishers remain under strict confinement, and thus let them enjoy the benefits of a stable runtime environment.

Could you please let us know if you have included the suggestions given and if you could make your snap work as best as possible without requiring classic?

11

Hello @emitorino

thank you for your comments. I fully understand the software classification requirement to grant or not the classic confinement. I still have read Security policy and sandboxing and I’m fully agree with the rigorous review process.

Anyway I’m now convinced glpi-agent is another case the process is not covering. I tried system-backup interface as suggested by @alexmurray. With some glpi-agent modifications it permits to fix few things (like the Os name), but really too few. I investigate a way to run native commands after a copy from hostfs but I didn’t find any efficient tool to also get the library dependencies.
“classic” confinement is definitively what glpi-agent requires.

As you remembered, classic confinement snaps run without restrictions and this is what requires the agent. I tried to explain you all the great care we take in the agent development and to make it work reliably across distributions I integrated a dedicated perl build in the snap. This perl interpreter was chosen for this software since the beginning to make it as portable as possible other platforms. The same perl code works great on linux, MacOS, Windows and more other.

To finally answer you last question, yes, I tried to include your suggestions and the solution were not enough to make it works as expected under strict confinement.

So is it possible to make an exception for this inventory software ?

Best regards

12

note that any snap, weather classic ot strict needs to ship all its runtime bits, just because your snap is classic you can not be sure all the libs and baries you want to call are available on the host, you need to ship everything the snap needs, classic just allows you less restrictions, but does not change the fact that a snap has to be self contained.

13

Yes, the only runtime glpi-agent really needs is perl and some perl libraries and I included them in the snap build. I included few recommanded runtimes as still explained like dmidecode, lsusb & lspci, but glpi-agent can run without them. So glpi-agent runs should be reliable.

1 Like
14

Unfortunately there are only certain categories under which classic confinement can be granted. And rather than exceptions, we always look for processes, tooling and/or even snapd improvements which can make the ecosystem better.

Have you tried snappy-debug during troubleshooting? It will recommend interfaces based on the behavior it observes in your snap. You can find instructions on about it here Debugging building snaps | Snapcraft documentation. Please try it and come back here with questions if you still cannot make your snap work.

There is also place for documentation improvements :). We understand the problem and we are also working on that. If meanwhile this helps, this is the snapd code repository: GitHub - canonical/snapd: The snapd and snap tools enable systems to work with .snap files.. You can find the interfaces at snapd/interfaces/builtin at master · canonical/snapd · GitHub (e.g. snapd/interfaces/builtin/mount_observe.go at master · canonical/snapd · GitHub)

Aha! Now I understand why my comments are long as well. You are talking with an Spanish native speaker here. So I totally understand you :wink:

15

Indeed, I can answer yes I tried the debug way and investigated the snapd source code to use it as documentation.
That just convinced me the glpi-agent is a special case strict confinement can’t cover. As I tried to explain and demonstrate here, such inventory agent was developed to be portable and as safe as possible from a past where no confinement technology was existing (the code base is more than 10 years old).
Then I think you should probably make an exception for glpi-agent and tolerate it uses classic confinement.

As a side question, in the case you will definitively deny classic confinement for glpi-agent, is it possible to use another store than snap store ?
Indeed I also just started to read that old thread about External repositories and I think the answer is no.

I’m disappointed as I think glpi-agent snap won’t finally be used if you can’t accept it is based on classic confinement. On my point of view, we still can distribute distro packages like rpm & deb for manual installation, so people won’t choose snap if it also need manual install with the “–dangerous” option.

16

Unfortunately not all classic confinement requests are granted. As store reviewers we need to employ the same set of guidelines for all snap reviews and at this stage there is not a category which would allow classic confinement for snaps which wish to inventory the system or similar. However, as noted previously it would appear glpi-agent could work under strict confinement but with a subset of functionality since it won’t be able to execute the host binaries - but it could enumerate them via the system-backup interface and it could then ship it’s own binaries to execute instead. So I feel there is still a reasonable solution if you wish to pursue it for a snap of glpi-agent.

17

Sorry, I’m giving up as this is not acceptable to deliver an agent with limited features. We will provide the snap built for classic confinement by GH Actions on our GH Releases page and people will have to install it manually.

We may later propose here another version dedicated to make remote inventory.