On Fri, 2014-05-23 at 16:46 +0200, Tollef Fog Heen wrote: > What's the deal about your use of ellipsises all the time? It looks > really weird and I'm not sure what you're trying to communicate by using > them. Uhm, guess I'm using that too much. It's just some kind of a break/pause - as you seem to use " ".
> > Sure... but that's how it is... I guess it's absolutely sure that there > > will always be software, which doesn't use e.g. NM (and given the issues > > I have with NM, I'm actually happy about that). > > But even if all software _would_ use NM (or something similar)... NM > > doesn't take care about e.g. netfilter rules. > > This has nothing to do with NM. Interfaces come and go on machines > running BGP daemons for instance. Or if you use IPv6 with > autoconfigured addresses. Ah, I thought you were thinking, that the daemon/system wich brings up/down any dynamic interfaces/addresses could take the duty of starting any "dependencies" like <load netfilter rules> as soon as the even of an new interface occurs. > > Sure... and don't get me wrong... I never tried to show that systemd is > > worse than sysvinit. > It's not about better or worse. Well I think it's worse in how it's actually used, since with sysvinit, simply "everyone" depended on $network, so one was automatically safe in a way. systemd could technically do better, but therefore I think we'd need something as what I've proposed in my last mail. > The same goes today. Depend on network.target and you'll have the same > things as you have today. Okay... don't understand why: On a server (not taking into account more complex scenarios when you also have e.g. NM that brings up an interface) the service that gives me e.g. eth0 is [email protected] (from [email protected]). That just requires basic.target. network.target is only wanted by networkting.service from LSB, which will eventually go away?! So I don't get how it is assured, that [email protected] would run before network.target, which btw: has just a Before=network.target... Still, AFIAU with systemd we try to reduce any single points like $network where many services depend on for some stuff, but they may not even need all of them. > > Well the upstream documentation I've referenced uses that phrases... > > claiming network.target was passive, while network-online.target was > > active. > > I did not find the phrase in the NetworkTarget web page at least. See also systemd.special(7): network-online.target [snip snap] Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up[1] for more information. network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up[1] for more information. > > Sure... what I meant was rather: > > Even though it's probably highly specialised... there may be setups > > which require the netfilter rules to beloaded even before the loopback > > is up. > > > > Though admittedly I haven't seen such... > > I'm not able to come up with a non-contrived case for that. Sure, if > somebody has compromised your init system, they can do bad things, but > that's not because they can talk to loopback, it's because they've > compromised your init system. Well doesn't Debian claim to be the Universal Operating System? So just because neither you or me can think now about some example, where have netfilter rules on loopback might be important, doesn't mean that there aren't any. So I think _if_ it's no big deal for us, to ensure that rules are loaded even before lo, then why not doing it? > > > There's nothing in the LSB definition that says «firewalls are up». If > > > you want that, have a ferm.service (or iptables-persistent.service if > > > you prefer that) that has Before=network.target and it will run before > > > you have «useful networking». > > > > Okay but I though network.target itself is rather something legacy... is > > it really like "policy" that all services that do networking depend on > > that? > > If they need it, sure. Hmm.. aha,... well there seem to be quite some services which DO networking but don't depend on it. And again,... this simply seems to somehow contradict one of the ideas of systemd. network.target means implies many (vaguely defined) things (and "netfilter rules loaded" is not even in their list)... why should a daemon, that is able to dynamically discover new interfaces wait for network.target, just so that it can be sure that netfilter rules are there, if it could load much earlier? Not to talk about that, AFAIU, this wouldn't allow us to have daemons not started if e.g. loading of the netfilter rules failed. > > It's good if a service doesn't depend (i.e. the daemon doesn't crash or > > whatever) if networking isn't there. > > Therefore most services would only say: > > Wants=networking.target > > Note that Wants/Requires does not imply ordering. Oh, of course... I forgot about the After? > > But if we do like you say above (i.e. iptables-persistent has > > Before=network.target)... then we have no real guarantee that the rules > > are up, when the service that Wants=networking.target starts. > > That is why they should also have After=network.target Okay so basically you say now: Any service that does networking should have a Wants=network.target After=network.target I think that's still much worse than what I proposed, since: - the service would load, even if e.g. iptables-persistent failed during loading - anyone that just wants to have iptables-persistent in place, but can live with "networking" (i.e. some interfaces up, DNS, etc.) being available later... would be delayed with start up. > > > you need the interface not to be brought up before you apply the > > > iptables rules. > > > > Sure.. I didn't claim that, did I? > > Actually the rules must be loaded BEFORE the ifaces are brougt up. > You claimed that it was the service start time which was interesting. Well it's both? Start it as early as possible,... but not before you're sure that the rules are in place. And as I'd say, don't start listening daemons at all, if the rules loading failed. > > So that means loading iptables could fail, but the services would still > > start => security issue > > If you require something harder, use RequiredBy. Note that it might > lead to stuff not loading if your iptables rules fail to load for some > reason. In some setups, that might be what you want, in other, you'd > rather have SSH running so you can log in and fix it. I guess the best solution here would be to have a BCP/default behaviour as I've described, i.e. daemons should depend on some "network-security" and they will not even start when that didn't load. SSH might be a special exception... since it's usually secure per default. But even ssh may be used in a way where one strongly wishes to have iptables in place... so in a case as SSH I would perhaps suggest to make it easily configurable via debconf? > If you care about security you need to monitor it. Yeah,... well I wrote about that a bit later in this mail... I don't think this is the right way to design systems: i.e. designing them insecure... and monitor whether that insecure condition really arises. If you depend on netfilter (and this is what one generally needs to assume) than you make your services not to start if it failed loading. You don't make some nagios which runs every day or so to check whether there are really some rules in place, or some port locked. This may be an additional security measure of course, but not the basic thing. > If you don't monitor > it, it doesn't exist. And no, I'd rather have SSH running and no > iptables rules loaded than no SSH and no iptables rules. One I can fix, > the other I can't (without physical or IPMI access). Well _if_ you really depend that strongly on access such nodes, than most definitely you want the to be secure even more than available. And further... _if_ you really run such important nodes... than you _have_ some other means of access (physical via support, remote console, IMPI, whatever) and if not, than you should rather get that. > > 2) These "things" must be in place, _before_ the service is used... e.g. > > netfilter rules must be loaded, _before_ the daemons start, _before_ the > > user could do any networking in his sessions, etc. ... or e.g. a TRNG > > must be activated, _before_ services want to use high quality entropy. > > > > If not, then one might have a short time frame, where e.g. postfix > > listens and networking is not secured... or where httpd makes TLS > > connections, but it still uses poor entropy from right after the system > > boot. > No. In some cases, having that window where an attacker might attack a > surface is perfectly acceptable. In other cases, it's a big deal. It > depends on the context. Well, to be honest, that's quite some disturbing view about security. An attacker usually doesn't have vacation when such "window" is open. Either such window exists and is there, than we should set up things in a way, that per default it's closed... or it's not there, then we don't have to act of course. But having services and user sessions depending on netfilter being up is really not that special and commonly done - this is why we have it. So if systemd is so nice to provide us with the means not to start services if the rules weren't loaded - then why not using that? The funny thing is that systemd folks is kinda known to "teach" people how things should be done right (and some people complain that this would break existing ways of handling stuff). But teaching them how to properly handle security and availability is not really accepted, with the reasons that things should work and being available always and out of the box. This is not a responsible way of running any system. > > 3) In systemd, we only want to start things when necessary... and also > > only want to pull in the least necessary stuff... i.e. if postfix > > auto-discovers new interfaces that go up and starts listening on them... > > we don't want it to depend on network.target (which already expects all > > the ifaces to be up)... but we DO want it to depend on "netfilter rules > > loaded". > > And having the netfilter rules loaded as an even (e.g. just before a new > > interface is brought up) just doesn't work in practise. > > So neither can we delegate that task to postfix, or to the > > program/service that brings up the interface (e.g. ifupdown, or NM).. we > > have to do it in the system start. > > If having netfilter rules is crucial to postfix' security (which I > really hope is not true) May be very easily the case, if you have e.g. mail submission secured via the source address, which is commonly used. > then it should depend on having the rules > loaded. If it's only a want to have it, use After=network.target and > Wants=network.target. Well it's not postfix or it's maintainer or any other daemon that decides whether Wants or Required is necessary. The thing is... it's perfectly valid to secure services by iptables (which is why we have it), so we must expect that people use it that way and depend on it. No with systemd we have some good way of defining that strong dependency ... why not doing it? Normally nobody should notice anything, since the rules are simply loaded and the Requires= is just as fine as the Wants=. And in case they aren't loaded for some error reason, there is no scenario in which it's better to have postfix started nevertheless and exposing you to some potential attacks. And THIS is actually what you should monitor: Whether or not your services are running. You cannot really monitor security, as you've said above, since one can only monitor a limited set of conditions. > > So if I didn't miss anything in that example,.. one sees how easy it can > > happen, that security is missed out. > > It's not black and white; not having the rules loaded for half a second > is «you don't have any security». Well it's not _guaranteed_ that you're screwed then... but it may happen extremely easy. Like most people have a rule which ACCEPTs any RELATED,ESTABLISHED connections. If your attacker connects to your service in just that half second, then his connection is ESTABLISHED and it will stay, even once the rules are loaded. If your intranet httpd serves content at httpd://company-secrets.example.org/ for just some second, that may be plenty of time to download most valuable data from there. So actually security done right _is_ black and white - I really wonder that so many people still don't get this after all the NSA scandal, where one can really see how powerful and sophisticated attacks are in practise. > > Now if I'm right so far, I guess two questions come up for each of such > > "things" like iptables/TRNG/etc. > > a) When and how (i.e. via which units) should it be pulled in? > network.target. See above > If you want high-quality entropy, use /dev/random, not > urandom. Well that's simply not done by all services... and even if... /dev/random may block, which may be undesirable. And even if you have some TRNG, or haveged or similar which feeds the kernel entropy pool to provide a high bandwidth in /dev/random, then this just emphasizes my point, namely that systemd should facilitate that it's loaded very early. > > b) What should happen, if the "thing" couldn't be started by systemd or > > if the daemon (if any) that runs "thing" fails/crashes. > Local policy. Sure,... but the default should be the secure one, which is that a service shouldn't start then. It may be local policy to allow remote root login without password - but just because this is an option, Debian doesn't default to it. It may be local policy to allow anyone in some local net in submitting mails via postfix - but just because this might be okay, we don't default to it. It may be local policy that TCP connections to postgresql are trusted - but we don't default to it. > > In my opinion, security always comes first, so I rather think that if > > e.g. iptables can't be loaded (perhaps because I did a typo) then my > > deamons should start neither. > > In some cases, sure. In other cases, no. Well than it's still that the no-cases should have to be manually selected by the admin,... and not the yes-cases. Admins shouldn't need to opt-in for security, but rather opt-out. > > [Actually I always have some slight hopes that you guys find some time > > to also look over the unit files once packages get systemd support and > > to see whether it's just some plain conversion from the sysvinit script > > to systemd, or whether it really uses all nice features of systemd that > > would make sense for the respective package (well at least I guess that > > not all package maintainers are systemd geeks as well ;-) ).] > > I know I won't have the time or interest to do so. I suspect the same > goes for the other systemd maintainers. Well I expected that,... but right now some services seem to be rather poorly converted from init-scripts to units... which somehow blocks a lot of the benefits that systemd would give. I don't say that this is your fault... it's just a pitty. > > How do we handle network security "things" that run after ifaces are > > brought up? Like VPNs or IPsec (actually I don't know, whether it's > > necessary to have ifaces up for these to be configured, but I guess so). > > I handle that via netfilter rules as well (i.e. I forbid any traffic > > that is non IPsec'ed, which I consider to be security critical). > > But for some people it may be useful to have a "network-secure-foo" > > which is pulled in after ifaces are up (of course again the problem with > > "which ifaces does that include?")... and which could pull in things > > like strongwan. > > > > But I guess this is a rather hacky thing and we should try to avoid it. > > If you need IPsec/VPN for security,... set that up in your netfilter > > rules (it's easy). > > If you need DNSSEC,.. simply don't add any resolvers that don't > > validate. > > All of this is deep within local configuration. Debian can offer some > defaults, but things like «don't allow non-IPSec traffic» obviously > won't fly in the default installation. As a start, you would not be > able to do network installations. Sure... that's what I tried to say above ("and we should try to avoid it"). I mean if someon depends on IPsec,... he must set up his netfilter rules so to secure things up. But _that_ in turn is what Debian should guarantee per default, that if you have something like iptables-persistent installed... then this comes "first", and services are only started if it worked. > Lots of those targets can be supplied by the local admin or another > package. If you do that and convince people to use them, more power to > you. We don't have the time and energy to do so within the systemd > team. Well I don't think there's so much you'd have to do, is there? It's adding some new targets, like my proposed network-secured.target (btw: fail2ban could be another candidate for being RequiredBy+Before by that),... writing somewhere to the wiki what it means, adding it to e.g. sysinit.target ... and if other maintainers ask you about "how do I convert my init scripts,... you mention it when you give them help". So the toughest part is probably thinking about some better name than "network-secured". I also don't think it should be supplied locally or by other packages... actually it should rather go upstream. If other packages provide it, then which? iptables-persistent? ferm? shorewall? Something new, which all other packages whose daemons would Require= it would need to depend on? Having such units provided by local admins make it lot of a burden to convert all your units to actually depend on it. I don't quite see what a system as I proposed it would make worse. It would be more secure out of the box, and if someone (like you with ssh) really says well I don't want to have that strong dependency as in Required= than it's easy to change it per service (e.g. change the Requires=network-secured.target of ssh to wa Wants)... or globally per security "thing", e.g. change the RequiredBy=network-secured.target of fail2ban to a WantedBy= ... but perhaps leave it at RequiredBy= for iptables-persistent But if the base thing, i.e. the Requires=network-secured.target isn't done by all daemons or other services that do networking,... than it's like not practically doable by the sysadmin. I mean even if you guys are not that much into strong security as it should be expected on every system, I'm a bit surprised to not really get some positive feedback here like "seems to be a good idea"... Having something like network.target which can be anything seems to contradict the systemd ideas... and I'd have expected it to be quite legacy. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
