Mandos on Fedora/RHEL

Mon Apr 1 16:03:00 CEST 2019

Hi guys,

At this moment it seems that Fedora / Redhat based systems are still not yet actively supported by Mandos and/or vice versa. I see no mandos packages in Fedora koji and no Fedora documentation on the mandos website. Have these POC's ever been finished? I think it would still have amazing benefit for Fedora / Redhat to have mandos work seemlessly in those environments.

Kind regards,
Erik.

> Op 8 november 2013 om 17:06 schreef "Nathanael D. Noblet" <nathanael at gnat.ca>:
> 
> 
> On 11/07/2013 10:07 AM, Björn Påhlsson wrote:
> > On 11/06/2013 06:07 PM, Nathanael D. Noblet wrote:
> >>> Huh, I do not recall dracut being this advanced last I checked, but
> >>> this was some time ago.  Do you know if this behavior occurs both
> >>> with and without systemd?
> >>
> >> So this advanced feature is part of systemd.
> >>
> >> http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/
> >
> > Password Agents is nice new feature, and looks identical to the
> > plugin-runner but agnostic to the type of querier. Less code for us to
> > maintain, and more stable way to do things.
> >
> > The splashy and usplash plugins would have to reimplemented or removed
> > (Could be deprecated given the age of those).
> >
> > As such, this looks like a good way forward (and future proof) to
> > write a mandos password agent and use plugin-runner as a legacy
> > support for non-systemd system s.
> 
> Sort of. CentOS/RHEL EOL aren't EOL [1] for at least 7-10 years. So we 
> would still need a non systemd version. The thing is with dracut they 
> have some networking support (no wifi that I'm aware of) - however I 
> would expect them to want the wifi support to be added to dracut and not 
> come from mandos if you know what I mean. So a dracut wifi module and a 
> dracut mandos module.
> 
> >> Granted dracut without systemd doesn't have the password agents it
> >> still has all the network functionality I think it needs to handle the
> >> interfaces. It also has a number of ways to ask for passwords.
> >
> > Since the Mandos network functionality is compatible with already
> > brought up network interfaces, it seems a bit unnecessary to try to
> > break out that part of the code. As long as the Dracut network module is
> > optional, mandos-client would also have to depend on that module.
> >
> > There are some open questions I have yet to research regarding the
> > Dracut network module. Does it support wireless networking setup? The
> > https://fedoraproject.org/wiki/Dracut/Options#Network documentation
> > does not seem to say so at this moment.
> 
> Yeah, no wifi. Though like I said dracut would probably prefer to handle 
> that as its own plugin.
> 
> As for the networking code in mandos client I think with some of the 
> changes below (like reading from a config) you could leave it in and the 
> default fedora package would 'disable' it via config.
> 
> >> So in my case Avahi is completely useless. I would love in fact to be
> >> able to provide a avahi enabled and avahi disabled client. In my
> >> particular case we have a small number of servers in different
> >> locations and so avahi is completely useless for me. I can see that it
> >> could be useful for others so I'm not saying it shouldn't be
> >> there. Plus I can imagine some people complaining about initramfs
> >> size. So allowing them to choose avahi vs non-avahi.
> >
> > As size goes, we are not using everything of Avahi project, but rather
> > only the subset included in the avahi-core package, which was designed
> > to be used primarily in embedded platforms. This was a conscious
> > choice to minimize the added size to initramfs. Note: the Avahi daemon
> > is not present.
> >
> > That said, it should not be that hard to implemented a build argument
> > for --no-avahi, but I personally consider that a secondary priority to
> > create a inital release package for Red Hat.
> 
> I agree. I wasn't aware it was using such a small dependency. Getting it 
> working on Redhat based systems would be fantastic!
> 
> >> The issue is its difficult to pass the mandos client any
> >> parameters. If it could read a parameter file I'd be set. Otherwise I
> >> have to modify it to read environment variables or modify the mandos
> >> ask-password-agent to read some variables and change how it calls
> >> mandos-client.
> >
> > With systemd and the password agent, mandos-client could use a config
> > file since plugin-runner.conf would no longer exist. That in turn
> > could then configure the service file, like adding --connect
> > server_address to the command line.
> >
> > How common is a non-systemd setup for Redhat? It would be preferable not
> > having one solution for current initramfs-tools without systemd, one for
> > dracut without systemd, and one for systemd that can be shared with
> > initramfs-tools and dracut.  Since systemd looks to be the future, it
> > would be better to simply develop towards that, and let the
> > initramfs-tools without systemd be deprecated in time.
> 
> So all non Fedora but Redhat projects use dracut without systemd. Fedora 
> with dracut uses systemd. The mandos client needs to have the same 
> changes for either. The difference will all lie in the dracut install 
> module. One will install a systemd service the other will install a 
> dracut script to run the client. In both cases plugin-runner is not 
> required as dracut basically is the plugin runner and has console and 
> plymouth password request modules.
> 
> >
> >> However one improvement would definitely be a way to set where
> >> everything is expected. For example there is no /conf/conf.d/mandos
> >> directory in the initramfs. It would be great to be able to set
> >> compile
> >> time options for most of that. Or have that all read from the same
> >> config.
> >
> > The /conf/conf.d/mandos is simply the directory which the
> > initramfs-tools made available, and at the time Mandos was written, it
> > was the only option available.  We could certainly use a built-in list
> > of directories to search for our files in.  A compile-time option, on
> > the other hand, introduces risk via the complication factor; suddenly
> > there would be many possible behaviors of the binary depending on
> > compilation options.  It is simpler to auto-detect on runtime.
> 
> The reason I say compile time is so that a user can't mess anything up. 
> With a compile time switch the dracut module, the mandos client and 
> everything expects it in the same spot. Without it a user could follow 
> any number of online guides putting things in different places and never 
> getting it to work. As its a boot time system, I'd prefer that we can 
> set this to one specific place and everything around it expects it all 
> in one place. Granted its your project so I'll deal with whatever you 
> decide.
> 
> > As I see it, the systemd mandos-agent can have in its service file all
> > the appropriate command line switches for mandos-client; this service
> > file will then serve as a config file.  If desired, this service file
> > could be generated at initramfs creation time based on a simpler config
> > file in, say, /etc/mandos/mandos-client.conf.
> >
> > (We do need a configuration directory, since we need somewhere to
> > store the key files.  I assume these should not be compiled into the
> > binary.)
> 
> I have no problem setting where they should be via compilation. To me 
> this provides distros with the most flexibility. Fedora wants it one 
> place, debian another, X,Y,Z can take it and put it somewhere else but 
> the code path remains the same.
> 
> As it stands now the default mandos-keygen for example expects 
> /etc/keys/mandos, there is no /etc/keys in fedora, there are also 
> differences between fedora and redhat/centos systems. So having a 
> compile time switch that sets a GCC define / Makefile for some paths 
> lets the code remain the same but lets a distro decide where it should 
> expect whatever it expects. This also helps with selinux integration.
> 
> 
> >> If the mandos sources were simply re-organized a bit I imagine it
> >> would be easy to do what I'm thinking. Something like having the
> >> necessary parts for the start_mandos_communication in its own source
> >> file. Then two more source files one with avahi one without. Both use
> >> the object file from start_mandos_comm to do the actual config.
> >
> > Using mandos-client without using ZeroConf is easy; just use the
> > --connect option.  If it's the size of the Avahi daemon you're worried
> > about, then let me reassure you, mandos-client uses only the
> > *avahi-core* library.  It is *not* dragging in the whole Avahi daemon
> > and the assorted avahi libraries. The library used by mandos-client is
> > 221K for an x86-64 system.  This is not, to me, a size significant
> > enough to warrant a split, especially not when considering that the use
> > of ZeroConf is what we view as the primary use case.  A single binary to
> > cover all use cases is simpler, especially now when we already will need
> > one additional binary (mandos-agent).
> 
> Sounds good to me!
> 
> 
> I wanted to try to make some of these changes in a bzr branch however I 
> have no idea how bzr works so I wasn't sure how do it and then provide 
> patches... It also seemed somewhat related to the whole 'compile time' 
> values vs adding multiple directories to search.
> 
> >
> > /Björn Påhlsson
> >
> 
> [1] - https://access.redhat.com/site/support/policy/updates/errata/
> 
> -- 
> Nathanael d. Noblet
> t 403.875.4613
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev