I understand fully what the reasoning is here, where you want average security from the ground up into the core of the server.
When I set up servers or systems, I rather prefer a really tough and hard shell around the network/system in question, and pretty sloppy security inside. Like a nut. Very tough to get in, but once you´re in, theres almost no security. That makes it a whole lot easier to administrate, since then I can easily integrate software more tightly in each other (for example DNS integrated with HTTP and SMTP and filters and everything), while I can concentrate on tight security at the perimeter. Think like a apartment. Your outer door is of course closed and locked, but your inner doors are always open. So I set up pretty restrictive firewall rules, and have filters, proxies and rules at the perimeter protection, to prevent any bad guys from getting in at all. On my servers, user's aren't even getting IMAP or SMTP relay access from the outside, since I think it’s a security risk. If they need that type of access, they have to use webmail, since that can be set up more securely with IP authorization, OTP codes and captcha security. If I need to separate things for security reasons, I rather put them on separate networks in firewall with strict rules in-between, rather than fiddling with permissions and getting that things working. So I think its just another way to administrate a server. Some people prefer average security everywhere, and some other prefer tough and restrictive security at the perimeter and then loose security inside. That’s why I 666's files to make it easier to administrate. -----Ursprungligt meddelande----- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Martin Skjöldebrand Skickat: den 20 februari 2016 10:26 Till: postfix-users@postfix.org Ämne: Re: SV: access permissions 101 On 20/02/16 02:05, Sebastian Nielsen wrote: > Everytime I need multiple processes to access the very same file and those > processes has interlocks that prevent them from running as the same user or > same group, I just "fix" the problem with 666. > > That is a thing I ONLY do if I get a permission error when trying to do > something I want to do with some software. So for example, when I want to > edit something from my admin panel on http://www.sebbe.eu , I just 666 that > file to be able to access it from the admin panel. > > Same, I needed to get arp working so HTTP could execute arp for detecting > which MAC addresses users of a captive portal had. I simply 777'd arp > command, because not even 755 worked for some reason, the arp command > required whoever that had execute permission to also have write permission. Apologies for butting in on this discussion. The above reasoning seems to me deeply flawed and something I was guilty of as a Linux newbie back in the late 90s. It is a tempting easy way out. Rather than addressing the cause of a problem, you are attacking the symptoms and in the process creating unnecessary vulnerabilities in the system. At least that is how I read your brief description. The problem with this, to my mind, is that it introduces sloppyness and this can influence future actions and sub-par "solutions" permanenting potentially harmful workarounds. On my own home gaming box, it's one thing, on a company or client server on the other hand ... /Martin S > > Yeah, I agree that actually, only 644 is required on that config file. But > why get so angry when someone 666's a file to just get things working? > Its not like a list of banned spam domains is something super-sensitive. > > > -----Ursprungligt meddelande----- > Från: Jim Reid [mailto:j...@rfc1035.com] > Skickat: den 20 februari 2016 01:40 > Till: Sebastian Nielsen <sebast...@sebbe.eu> > Kopia: postfix-users@postfix.org > Ämne: access permissions 101 > > >> On 19 Feb 2016, at 23:52, Sebastian Nielsen <sebast...@sebbe.eu> wrote: >> >> but if you're hosting for example a mail server for a company, and only you >> as a sysadmin has shell access to the server, its no danger 666'ing files >> that throw permission errors. Then the file isn't really "world writable", >> since only you have a account on the server anyways. > This is a remarkably stupid and utterly irresponsible thing to say. It’s also > wrong. Very, very wrong. > > One of the fundamental principles of security is least privilege. Things get > the minimum permissions/access rights/whatever that are needed for the task > they have to perform. > > So for postfix only some postfix processes need to have write access from > time to time to specific files and directories. Almost nothing should ever > need write access to postfix's configuration files, except for maybe postmap > when rebuilding hash tables. So postfix's config files shouldn’t be writable > by anyone, not even the postfix user. > > Your starting assumption is also deeply flawed. A world-writable file can be > written to by anything, not just the UIDs who have shell accounts. There will > be other (or should be) UIDs and GIDs allocated to other services that run on > the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man > pages, TeX, FTP, etc, etc. That way if one of these things has a security > leak, it can only write to that UID’s writable files (if there are any). The > breakage can’t contaminate anything else. But if someone is stupid enough to > intentionally make config files world-writable, these can be damaged by a > security problem in a rogue application. This is why the TeX user (say) > doesn’t get write access to the DNS or mail or MySQl or.... configuration. > That UID doesn’t need those privileges. So it doesn’t get them. At least, not > on any sensibly managed computer system. > > The logical extension of your approach is to make the password file, kernel, > shared library, etc world-writable. After all, you’re the only one who has > shell access. And you never, ever make mistakes and no software > vulnerabilities of any sort ever occur on the servers you manage - right? > > If you were hosting mail for my business and I found out you’d *deliberately* > set 666 permissions on the mail configuration files my company depended on, > I’d sue you for gross negligence. And win. > > > -- This address is for technical mail lists only.For all other matters, please use my main addressat the .org domain.
smime.p7s
Description: S/MIME Cryptographic Signature
