On Fri, Dec 08, 2023 at 12:14:09PM -0500, Steve Grubb wrote: > On Friday, December 8, 2023 11:57:55 AM EST Adam Williamson wrote: > > On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote: > > > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > But yeah, there'll always be a few "special" files. But that's fine, > > > > we have mechanisms to handle those. For the other 99%, we should > > > > move them out of /etc. > > > > > > > > > The problem is that there would need to be a standard that all upstream > > > authors agree on. There are some like systemd which have a [SECTION_NAME] > > > > followed by config items. Others do not make sections. What if the > > > config is in yaml, json, or XML? How can you see the end result? We > > > would need to have a standard library that everyone can use. From that, > > > we need a utility to compile the actual configuration that would be > > > consumed by the service so we can inspect it during troubleshooting. > > > > Eh? What does the format of the files have to do with where they live? > > At face value, it shouldn't matter. But when you have the first override, now > you need to have a reproducible, correct assembly of the configuration. Each > format has peculiarities about how to place the override in the correct spot. I think that there's a misunderstanding because there are two separate ideas in play: 1. moving of the default "main" config file from /etc or somewhere under /usr and allowing the the file in /etc as an override. 2. allowing extensions of that configuration with additional "drop-ins". Systemd implements both, so people tend to think of them together, but strictly speaking, they are completely orthgonal. Systemd has it easy, because its INI config files can be just contatenated. As AdamW said, there are formats like XML or JSON where this wouldn't work. *Some* custom mechanism of extension may be defined, but it won't be a trivial sort-and-concatenate. Points 1 and 2 each separately are beneficial. 1. has all the advantages that I described in the initial mail, 2. has the advantage that it's much becomes trivial to insert and remove "edits" to the configuration, and it's easy to combine configuration from multiple sources, e.g. main package, extension packages, and local overrides. If we don't have that, we must do some scripting to "merge" additional config, but in many cases this is very brittle. 1. + 2. together gives the most benefits. > > I don't see any reason we can have heterodox config file formats in > > /etc, but not in /usr. (Indeed, practically speaking, we already have > > lots of different formats in both places). > > Because it's in one place and not expected to be built up by looking all over > the place for the pieces. Making this easy for security scanner and upstream > developer adoption really needs to be considered. Don't misunderstand that > I'm against the idea...I'm just trying to say we need to consider the > ramifications across the broader ecosystem. If a given program only supports item 1. above, then there's no merging. But I agree with the more general premise: security scanners and other software needs to "understand" and support the effective configuration mechanism. In an earlier mail, Steve Grubb wrote: > The problem is that there would need to be a standard that all upstream > authors agree on. There are some like systemd which have a [SECTION_NAME] > followed by config items. Others do not make sections. What if the config is in > yaml, json, or XML? How can you see the end result? We would need to have a > standard library that everyone can use. From that, we need a utility to > compile the actual configuration that would be consumed by the service so we > can inspect it during troubleshooting. All those problems already exist. We have hundreds of custom file formats in play. Even the same software can change over time, adding new syntax. So to make *any* inference about some piece of configuration, the scanner or other tool needs to support that specific configuration format. What's even harder, it must understand the implicit defaults. If frobnicator-1.0 defaults to "allow everything", and frobnicator-2.0 defaults ot "deny everything", a scanner that supports the syntax of the configuration, but doesn't know this, is not very useful. All of that is already true, and the additional complication of multiple config file locations is just a small addition on top. > Without this, security scanners are going to have a hard time determining > what the security posture of a system is. And the Security Content everywhere > will need to be changed, STIG, Common Criteria, CIS, USGCB, etc. Some of > these are very opinionated about the file permissions. Something would have to > check all files everywhere that make up a configuration. Again, security > scanners are not going to like this. So, the library would also probably need > to be able report all permissions used or set all permissions used. And then > there is the SE Linux labeling... Those tools already have this problem. No matter what Fedora does, various upstreams are already adding support, so those scanners need to implement that too. SELinux labelling should be easy: the file under /usr is part of the package payload, so (as the Packaging Guidelines require) it must be world-readable, and we don't really need SELinux to do anything special. > There would probably need to be some written standard on how to assess the > system security posture in this kind of world. This way tools can be adjusted > using the standards. https://uapi-group.org/specifications/specs/configuration_files_specification/ lays out some general recommendations. But as I wrote above, I think that the hard part is details of the application-specific logic. The only general standard is: "take implicit defaults, all the configuration on disk, figure out what those two mean when combined for the installed version of the software, then assess". Doing this correctly for the myriad programs out there is a tough job. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
