Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9122

Please consider tcp wrappers support in all MariaDB packages/distros

Details

    Description

      Hello,
      What do you think about enabling libwrap in all packages by default?
      It gives an additional (and easy-to-control) layer of security, right before anything hits MariaDB internal access verification. FWs sometimes are ugly and not working under high load, plus not everybody uses clouds to keep things secured.
      I would recompile it myself, as I am usually doing with all RPMs in my systems (I work with CentOS), however, cmake/bazaar is a real headache to work with/support (IMHO), tried few times and find myself investing too much time into it though I could compile MariaDB with it in the end.

      Your page about "considering source rpm" is too old and no news. Maybe it can be done out of box?

      I am used to compile almost everything from source rpms and adjust everything I need on the fly, so don't mind to have source rpm as well. But if everything remains as is - well,no choice then and need to either reconsider security again or get back to bazaar/cmake journey...

      Thanks!
      Alex

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            Isn't MDEV-6284 remov(ing|ed) libwrap from Debian?

            Honestly I doubt libwrap can do better performance under high load than a stateless firewall doing the same job.

            This would add an additional dependency so can't be done during a stable release.

            So referring to clouds are you saying there has to be some access control beyond the mysql authentication on uncontrolled interfaces? I agree.

            I do see libwrap as something old and antiquated and probably just as ugly as your perception of firewalls. Sorry, I don't think enabling libwrap by default is a good idea.

            Currently you can bind to a local network address (--bind-address=192.168.1.0).

            I'm going to repackage my systemd socket activation patches (MDEV-5536) soon will provide the ability to bind to multiple local network interfaces, which is less capability than libwrap or firewall rules, however maybe that can meet your needs?

            danblack Daniel Black added a comment - Isn't MDEV-6284 remov(ing|ed) libwrap from Debian? Honestly I doubt libwrap can do better performance under high load than a stateless firewall doing the same job. This would add an additional dependency so can't be done during a stable release. So referring to clouds are you saying there has to be some access control beyond the mysql authentication on uncontrolled interfaces? I agree. I do see libwrap as something old and antiquated and probably just as ugly as your perception of firewalls. Sorry, I don't think enabling libwrap by default is a good idea. Currently you can bind to a local network address (--bind-address=192.168.1.0). I'm going to repackage my systemd socket activation patches ( MDEV-5536 ) soon will provide the ability to bind to multiple local network interfaces, which is less capability than libwrap or firewall rules, however maybe that can meet your needs?
            ShivaS Alex added a comment - - edited

            Hi Daniel and thanks for looking into this!

            I am not sure tcp wrappers are old and ugly, I do know many people that keep using hosts.allow file for controlling ssh access for example (including myself), and it's still sounds like a good idea to me to not let the connection hit the application authentication level until checked by hosts.allow for example. And I never liked firewalls
            In clouds you have a granular support over source/destination access, while in physical hosting or in hosting where real IP set on host machine it's a bit of a headache.

            I have MariaDB spread over dozen of virtual machines (on physical servers) in different corners of the world, all of which needs to replicate either for purpose of HA (DRP) or backups. Today I am using VPN tunnels between such locations. I have 2 LAN interfaces, one used for APP access and the other one for VPN (which is used for both internet, replication and remote access). No external access, and MariaDB listens to 0.0.0.0 in such case.
            The whole solution requires many things to be supported such as additional networking/vpn for example. All of that results in additional time/monitoring/checks to be invested. So getting back to WAN/LAN interfaces on the same machine, and using hosts.allow file seems like to be a good solution with less headache to support all the security/networking solutions I've mentioned. Maybe that's only me and maybe libwrap is old and ugly as you say.
            I also wouldn't mind recompiling MariaDB and making my own distribution to support it, but there is no source rpm and seems like it's not gonna change ;(

            So here is my situation and my explanation for having libwrap. I see the things are not gonna change, and you have reasons for that.
            I would appreciate the source RPM introduction! For now I am going to have another look at bazaar/cmake and see if I can make it faster this time...

            Thanks again for looking into this!

            Alex

            ShivaS Alex added a comment - - edited Hi Daniel and thanks for looking into this! I am not sure tcp wrappers are old and ugly, I do know many people that keep using hosts.allow file for controlling ssh access for example (including myself), and it's still sounds like a good idea to me to not let the connection hit the application authentication level until checked by hosts.allow for example. And I never liked firewalls In clouds you have a granular support over source/destination access, while in physical hosting or in hosting where real IP set on host machine it's a bit of a headache. I have MariaDB spread over dozen of virtual machines (on physical servers) in different corners of the world, all of which needs to replicate either for purpose of HA (DRP) or backups. Today I am using VPN tunnels between such locations. I have 2 LAN interfaces, one used for APP access and the other one for VPN (which is used for both internet, replication and remote access). No external access, and MariaDB listens to 0.0.0.0 in such case. The whole solution requires many things to be supported such as additional networking/vpn for example. All of that results in additional time/monitoring/checks to be invested. So getting back to WAN/LAN interfaces on the same machine, and using hosts.allow file seems like to be a good solution with less headache to support all the security/networking solutions I've mentioned. Maybe that's only me and maybe libwrap is old and ugly as you say. I also wouldn't mind recompiling MariaDB and making my own distribution to support it, but there is no source rpm and seems like it's not gonna change ;( So here is my situation and my explanation for having libwrap. I see the things are not gonna change, and you have reasons for that. I would appreciate the source RPM introduction! For now I am going to have another look at bazaar/cmake and see if I can make it faster this time... Thanks again for looking into this! Alex
            danblack Daniel Black added a comment -

            Good explanation.

            btw, to produce rpms (in this case for f22 - suffix on rpm)

            cmake .  -DBUILD_CONFIG=mysql_release -DRPM=f22 -DWITH_JEMALLOC=system -DWITH_LIBWRAP=ON
            make -j9 package

            The systemd patches I'll do will supported a limited number of binding interfaces.

            danblack Daniel Black added a comment - Good explanation. btw, to produce rpms (in this case for f22 - suffix on rpm) cmake . -DBUILD_CONFIG=mysql_release -DRPM=f22 -DWITH_JEMALLOC=system -DWITH_LIBWRAP=ON make -j9 package The systemd patches I'll do will supported a limited number of binding interfaces.
            ShivaS Alex added a comment -

            Thanks!
            I'll try compiling my own rpm the upcoming week (also will check RHEL/CentOS's source rpms)

            ShivaS Alex added a comment - Thanks! I'll try compiling my own rpm the upcoming week (also will check RHEL/CentOS's source rpms)

            libwrap is deprecated in Debian and Ubuntu, we will not ever start using it anymore

            otto Otto Kekäläinen added a comment - libwrap is deprecated in Debian and Ubuntu, we will not ever start using it anymore

            People

              otto Otto Kekäläinen
              ShivaS Alex
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.