Re: F21 Self Contained Change: Security Policy In The Installer
On Mon, 2014-03-17 at 14:52 -0700, Adam Williamson wrote: On Mon, 2014-03-17 at 13:10 +0100, Vratislav Podzimek wrote: And to sum it up a bit -- I think this feature doesn't complicate things for users who want to ignore it or who don't understand it. If you think it does, please tell me about it and I'll do my best to fix it. On the other hand, if somebody wants to care about security policies, they have an easy and comfortable choice. Unfortunately, I don't think this is quite right. As I understand it, it's fairly well established that if people see a UI element, they - or, at least, an appreciable amount of them - will want to interact with it, or at least understand it. *Some* people may follow this thought process: Path 1 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, I guess I'll just ignore it and carry on. which is what you're assuming, and would give an okay outcome. However, I think it's fairly well known that quite a lot of people will follow this one: Path 2 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, crap. I'm installing an OS. That's a pretty major operation. I think I'd better understand everything that's going on before I carry on. clickety Huh. content...policy...profile? What is all this stuff about? What does it mean? What should I do? This one goes one of about three ways. If we're really lucky: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! If we're less lucky: I guess I'll go Google around and see if I find something useful. Jeez, why does this have to be so complicated? If we're less lucky: Man, screw this crap, if I have to go read an encyclopaedia just to get it installed, I'll go do something else. And finally, some people will probably follow this one: Path 3 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, what the hell, I'm a smart cookie, I'll just power through. clickety Hum. Content...policy...profile? I don't really know what any of those things are. But reading is hard. I'll just make some sensible-looking guesses! clickety I suspect you can figure out the possible outcomes of path 3. ;) Well, I still believe that if we had good content in the SSG, sensible-looking guesses and the addon was able to show rules defined by profiles (which is a planned feature for the next release), it would be quite an easy choice for the user. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Mar 17, 2014 at 02:52:43PM -0700, Adam Williamson wrote: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! I clearly didn't write that explaination, then. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTKF7RAAoJEB/kgVGp2CYvTCkL/AnFBBEeu0gVTHL+705IhrJU 93o08hcjWocEnnAkRCYMZBnaiS3Sa18O5THCOXEJvMqgfCxxwOgU5BNvNRgIe+V6 /xQUVkOdXWS/waHHG7jdroXJnDjZ/sM51Xtuy0J/G2zLmNQ723NOE3xm+heSF6aW 68g1vX40kKIUrTAK2YJJaibP2C5WgNcDn8nktnSgPLGPGkIcbIV1dQofRadBfyXD 3xL+lduV48l5KmRHq8vVrWDEp2CKK1A1rNDdFWie/KEwcs2qV+VESbIjCnKI+3Bd PeHEkq2E/PNaA7vrzrXYSuLZ60GB6pe5UrZiq2V8+Bx5MbjFo7Tr6Z5LQo8iBPaM RgLjqDtTVdFOkJpLTGFVjjTZw9tlh6UlGr8j65bBqHlzg5oyo0p86ZoCZNqvyqBq qn+nwVxOiX/fQNVuea6aluhHACrSqWEI9B8lKHt8whZ1cPEZ42V8oQvUCXzQzxEP opHt9/MT5dlEX6/LiTu8PVWpXCLpHCoyoraJL2Vl4g== =b+ZF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Tue, 2014-03-18 at 10:57 -0400, Eric H. Christensen wrote: On Mon, Mar 17, 2014 at 02:52:43PM -0700, Adam Williamson wrote: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! I clearly didn't write that explaination, then. Me either :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Sun, 2014-03-16 at 22:05 -0400, Bill Nottingham wrote: Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? I can be part of the System category. It hasn't been from the beginning because there was no System category when this project was started. INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive (2) If this is still desired There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. URL SCREEN == - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection, if it is not the normal source of the choices in the initial screen? If we're shipping with predefined content sources, it should be reflected on the initial screen; if we're not using that predefined data, I'm not sure why it's an option here. Choosing SSG doesn't result in using a predefined URL, it results in using content that is a part of the compose, setting various parameters. - 'Enter data stream content or archive URL here'. Again, too jargon-y. Is there a reason 'Enter URL to security policy' isn't good enough? (Or whatever terminology is used in the software spoke.) Good point. However, we would need at least a tooltip on which security policy formats are supported. PROFILE DETAILS === It's best when describing details (if we want to do so) that we don't use different terminology or concepts than what is used in the rest of the installer, if at all possible. In your example, we have: - 'logical volume' This only shows up in custom partitioning, and even then not very foregrounded (unless I'm missing something). - 'mount options' Not used anywhere. - 'package', 'list of installed packages', 'list of excluded packages' Packages are not exposed in the installer UI as user-interactable objects - the only place they show up (outside of error messages) is as part of the installation progress bar. I take all those terms as commonly known or, in case of logical volume, something that can be simply ignored if not understood. Above and beyond that: - We should not be showing things as warnings. If the policy says a password must meet certain parameters, and we let the user later set it up in a way that violates that without additional warnings or automatic remediation, that's a bug. I agree, but before this is fixed (a change in the anaconda installer needed), displaying a warning is better than nothing to me. - The error situation is even worse. It's really bad form to show them an error in spoke A *that they inherently have to know how to fix in spoke B*. Otherwise, you're giving them an easy way to break their system that they won't know how to get out of, with no
Re: F21 Self Contained Change: Security Policy In The Installer
Thank you for the proposal, Bill. - Original Message - From: Bill Nottingham nott...@splat.cc Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? Will leave reply to this item to Vratislav (since I am not familiar with Anaconda plug-ins internals). Vratislav, can you clarify if this would be possible to implement by changing the current design? INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. Fair enough. To be consistent I would recommend we to stick just with the security policy (and forget about the other possibly confusing terms) [*] If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: rename Choose another policy source... button to read Load external security policy... Let me try to iterate on your proposal. Just a note (small correction) -- within policy we aren't selecting sub-policies, but rather profiles (just question of naming convention). FWICT I like your proposal in general, with small possible enhancements: * have SCAP security guide policy loaded / selected by default, * mention policy name in the middle of Apply ... toggle, * provide description for each profile at the right side (as you proposed) Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive Agree with this item. (2) If this is still desired As pointed out by other people in this thread too, having a way to select which policy to apply is good (just for the case the more experienced user might want to supply own modified policy). But agree with that point, that for example on https:// URLs the certificate should be verified for validity (didn't try if it actually is already). There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. +1. Agree that Select Profile button is redundant (not needed) here. The slight modification of your proposal is listed below: Apply SCAP Security Guide security policy [ YES | NO ] --- | (Maybe description of the whole policy here?) | | | | | --- Choose security profile: [**] --- Common Profile |Longer description of the profile Summary of the profile |shown upon selection --- Server Profile |Longer description -||- Summary of the Server profile | --- .. |.. .. |
Re: F21 Self Contained Change: Security Policy In The Installer
Can you be more concrete which term(s) you don't understand? Maybe you are right and the concept needs to be better explained / presented differently prior wider adoption [**]. What is a Data stream? What is a Checklist? How do I know which ones to pick? Datastream is one of the format security policy can be provided in. Checklist is list of rules the features of the system to be installed are to be checked against. But I got your point that we should focus to present this as much easy as possible (possibly removing jargon words / replacing them with their more clear equivalents etc.) Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
- Original Message - From: Chris Murphy li...@colorremedies.com On Mar 14, 2014, at 1:06 PM, Eric H. Christensen spa...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 06:59:18PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I think Matthew is making a reasonable assumption that many (probably even most) other users will become confused to the point of being disturbed by something that seems to require their attention, has a UI with terms they aren't likely familiar with, while suggesting choices, yet at the moment there's only one policy (?) so why is a UI needed for this right now? This is usually what kickstart installs are for. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. At this point it doesn't appear to need a UI. There's no off or on switch, or opt in or opt out. There's one policy. I'd say even with three policies available I'm much better off with a slider that says Standard Security - More Secure - Most Secure. I mean, that's sufficiently dumbed down I still don't know what those things actually mean in terms of policy or behaviors, but relative to each other I've made a more informed decision than what I'm currently presented with. The problem with this proposal (Standard Security - More - Most within slider) being it's binding the current SCAP security guide content with Anaconda add-on too much (IOW it's not flexible). What if in the future we would like to have five instead of three profiles? Another point is that due to different targeted use of profiles (server vs cloud security etc.) it's not possible to decide which of the profiles is more safer (i.e. use linear scaling from less secure to the most secure). It would be possible if each profile would be implemented as inheriting from his predecessor. But this is not the case always (server vs cloud) - on one hand there would be rules both of them would derive from their parent (common), but on the other hand there would be also usage specific rules (IOW server not having those from cloud and vice versa). I mean honestly how complicated does an OS install need to be? It's like piling on the user. It does need a default, like Timezone spoke, even though sometimes that too is set wrong for a particular user. The default avoids the requirement the user enter the spoke. It should be a minimum recommended security policy. The next question I have is how this spoke can affect other spokes, as well as affect the installation process itself? What I'm looking for is some assessment of impact on QA resources needed to test this feature, if any resources are needed at all. If there's no default but the user must interact with this spoke to proceed with installation, that's definitely a QA impact. Common profile from SCAP security guide would be the default policy (if to apply security policy toggle button was toggled on). Would we know more details about the system from the start (i.e. if it's to be standalone server installation or movable laptop edition we could use even more specific default profile). There's maybe one or two toothbrush wrappers of spare resources in QA (and I'm already imagining Adam feverishly writing a reply, UMMM, I don't think so, where?!) So if it's even remotely possible for a security policy to be chosen that later causes some sort of install, or even a first boot failure to happen - that's too much QA impact right now, short of a recruitment drive. There would be two levels of testing required: * one group to test the functionality of OSCAP Anaconda Addon (i.e. if it works properly). Assuming, this would be done within Fedora Anaconda
Re: F21 Self Contained Change: Security Policy In The Installer
On Mon, 2014-03-17 at 13:10 +0100, Vratislav Podzimek wrote: And to sum it up a bit -- I think this feature doesn't complicate things for users who want to ignore it or who don't understand it. If you think it does, please tell me about it and I'll do my best to fix it. On the other hand, if somebody wants to care about security policies, they have an easy and comfortable choice. Unfortunately, I don't think this is quite right. As I understand it, it's fairly well established that if people see a UI element, they - or, at least, an appreciable amount of them - will want to interact with it, or at least understand it. *Some* people may follow this thought process: Path 1 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, I guess I'll just ignore it and carry on. which is what you're assuming, and would give an okay outcome. However, I think it's fairly well known that quite a lot of people will follow this one: Path 2 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, crap. I'm installing an OS. That's a pretty major operation. I think I'd better understand everything that's going on before I carry on. clickety Huh. content...policy...profile? What is all this stuff about? What does it mean? What should I do? This one goes one of about three ways. If we're really lucky: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! If we're less lucky: I guess I'll go Google around and see if I find something useful. Jeez, why does this have to be so complicated? If we're less lucky: Man, screw this crap, if I have to go read an encyclopaedia just to get it installed, I'll go do something else. And finally, some people will probably follow this one: Path 3 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, what the hell, I'm a smart cookie, I'll just power through. clickety Hum. Content...policy...profile? I don't really know what any of those things are. But reading is hard. I'll just make some sensible-looking guesses! clickety I suspect you can figure out the possible outcomes of path 3. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 13:38 -0400, David Malcolm wrote: On Thu, 2014-03-13 at 15:27 +0100, Vratislav Podzimek wrote: On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. Will the spoke's label have some text like No security profile selected or somesuch when that's the case? Presumably the Begin Installation is insensitive until the Security Profile spoke is happy, like how other spokes work? I like the overall idea, but I'm slightly nervous about the UI. How, if at all, do security policies affect the UI in the *other* spokes? (sorry, I wasn't able to view your videos on this box, just the screenshots). For example, if you have a security profile which mandates that /tmp be on a separate partition or logical volume, does this affect the UI in the partitioning spoke? Similarly, if the profile forbids package telnet from being installed, does this show up somehow in the Software Selection spoke? (e.g. what if the user tries to manually select telnet within that spoke?). Likewise, does the Profile's password complexity requirements affect the password UI? Or is it a case of: review the issues listed in the Security Profile spoke, and figure out how do I fix this?, switch to the appropriate spoke, try to fix it, see if the Security Profile spoke is now happy, else repeat. That seems suboptimal, though what you've got may well be good enough for a first iteration (and I'm not volunteering to hack on it, so feel free to ignore me ;) ). Hope this is constructive; as I said, I like the proposal. Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive (2) If this is still desired There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. URL SCREEN == - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection, if it is not the normal source of the choices in the initial screen? If we're shipping with predefined content sources, it should be reflected on the initial screen; if we're not using that predefined data, I'm not sure why it's an option here. - 'Enter data stream content or archive URL here'. Again, too jargon-y. Is there a reason 'Enter URL to security policy' isn't good enough? (Or whatever terminology is used in the software spoke.) PROFILE DETAILS === It's best when describing details (if we want to do so) that we don't use different terminology or concepts than what is used in the rest of the installer, if at all possible. In your example, we have: - 'logical volume' This only shows up in custom partitioning, and even then not very foregrounded (unless I'm missing something). - 'mount options' Not used anywhere. - 'package', 'list of installed packages', 'list of excluded packages' Packages are not exposed in the installer UI as user-interactable objects - the only place they show up (outside of error messages) is as part of the installation progress bar. Above and beyond that: - We should not be showing things as warnings. If the policy says a password must meet certain parameters, and we let the user later set it up in a way that violates that without additional warnings or automatic remediation, that's a bug. - The error situation is even worse. It's really bad form to show them an error in spoke A *that they inherently have to know how to fix in spoke B*. Otherwise, you're giving them an easy way to break their system that they won't know how to get out of, with no indication of where they have to go to fix it. Selecting the error should take them to the screen where they can fix it, and it should be a 'normal' installer screen that they've seen and can get documentation on, not something 5 layers deep in a custom workflow that they wouldn't know how to get to again. ... Given that, I think the interactive UI could use some significant rework before we put it in Fedora's installation images by default. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
- Original Message - Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? I'd say this is a nice feature for Server product, of course, does not make much sense to be shown by default in Workstation product installer. One more thing - there's System Wide Crypto policy Change proposed, would it make sense to be covered by this spoke too? Or are there any other security related bits for Anaconda? Jaroslav What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. The possibilities of SCAP protocol: [1] http://scap.nist.gov/ [2] http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf [3] http://en.wikipedia.org/wiki/Security_Content_Automation_Protocol are not limited to enterprise-level Linux infrastructure. More from [2]: SCAP is a multi - purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement. Is any Fedora 21 product targeted mainly for enterprise deployment? The vice versa view. Rather effort to use security configuration, vulnerability and patch management also in Fedora product(s) (provide necessary tools to allow it). The content itself will differ depending on the fact if it's used in enterprise-level or academic / personal-level (enterprise-level companies required their systems to meet the federal agencies standards for example etc.), but security hardening guides / tips are applicable to Fedora OS instances too (IOW you don't need to be an enterprise-level company to require / prefer system to be secured and have ways how to tune in various aspects of system's security). So this proposal is to provide such tools. Is OpenSCAP being retargeted for general purpose level infrastructure. Not sure it was ever dedicated / restricted to be enterprise-level only. From [3]: The Security Content Automation Protocol (SCAP), pronounced “ess-cap”, combines a number of open standards that are used to enumerate software flaws and configuration issues related to security ... It is a method for using those open standards for automated vulnerability management, measurement, and policy compliance evaluation. There's nothing about it being exclusive just to enterprise-level infrastructure (actually in contrast the open standards are highlighted couple of times above). Of course writing the content requires time resources. So it's more likely enterprise-companies will have dedicated funds to support content creation of their needs. But the standard itself (AFAICT) doesn't enforce / allows it to be used in enterprise-level infrastructure only. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? The answer depends how many Fedora users care about security of their Fedora systems and would be interested / willing to spend some time to harden it via the possibilities provided by this proposal. What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? Of course there exists other ways how to achieve the same. The motivation why the proposal should get into wider user knowledge / awareness being it's flexibility when trying to manage security configuration, vulnerability checks, and also patches. There exists means how the provided security policy can be adjusted to reflect the particular targeted purpose (profiles modified to contain just subset of provided rules, apply various subsets to various systems etc.) -- for example via the scap-workbench tool: https://fedorahosted.org/scap-workbench/ Naturally it can be done via post-install for example too. The question is how that implementation would be adaptable to new requirements / security policy change requirements during the time / based on targeted system's application though. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
- Original Message - Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? I'd say this is a nice feature for Server product, of course, does not make much sense to be shown by default in Workstation product installer. One more thing - there's System Wide Crypto policy Change proposed, would it make sense to be covered by this spoke too? Depends what you mean under to be covered by this spoke too - once the Nikos' CryptoPolicy proposal is implemented we can definitely add a SSG content rule, that when selected would return failure as result of the scan on system not meeting the requirement LEVEL-* requirement. But if under covered by this spoke too you meant there should be another explicit field for CRYPTO POLICY in the proposed SECURITY section (allowing the user to select from proposed levels like LEVEL-128, LEVEL-256 etc), I am not sure it is necessary (since as noted above the desired level can be enforced by policy rule specification / implementation). Can you clarify? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team Or are there any other security related bits for Anaconda? Jaroslav What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 05:05:28AM -0400, Jaroslav Reznik wrote: - Original Message - Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? I'd say this is a nice feature for Server product, of course, does not make much sense to be shown by default in Workstation product installer. I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTIwM6AAoJEB/kgVGp2CYv9t0L/RHQkLR08o5FKfk1sehbcLlA iVVCJuaOyPxdWZ4GiFxEKX1PYx2Pe62LkjGxs0ydac3A32dxj5KLzaZPMBAh+SPZ iXSp95iX9YboE6q3SsbY7a4L4YvP0pT0LYbq5HF7deGIHSE2SK7plXdLT/p5bONe 7U2DLyrqZ+YNiOwS/jdHdBJ0DbJX6v5rul1wmgqSTtGOgvMYrLkY/Jh53KDEXuEX N1j1AjIbOtRPOFHRv1+pW+r/neJ91t29rNNHnZias3ggb2LaFrcGV2f/Sq78643A InGvfAvmftStxdDoBHyiLR6WetPdnY36w/b4y8TesNUxHr57gUhlds8LHd15hFMZ wGvMGt/4FgFCINWk5zdv2rFDvPgd+3Lba18IP8NLMT2cuP6SU7qDI3oRvvGksYj8 tClhbJjVNZKEg0qtgWpInO6i9Zf/Cs9Zbc9wFJNdwYYdxqqxUyR5oT2GhaRDMKvf BsqwuC2dulVUwVw4SOH7O6ihqgmIn2A136LPwlg3Ng== =ZC2s -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 06:25:03AM -0400, Jan Lieskovsky wrote: One hypothetical [*] scenario coming to my mind being the users might be willing to provide customized policy content to Fedora installation. Let's suppose the case there is a SCAP content for vulnerability checking (and ensuring some restrictions) for Fedora systems. Something like is done for Red Hat Enterprise Linux case: https://www.redhat.com/security/data/metrics/ This seems pretty niche. The cost associated with it is UI that makes no sense to most users but is presented to them by default anyway. I think we should concentrate on finding a way to make this possible without compromising the common case. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Jan Lieskovsky (jlies...@redhat.com) said: Is any Fedora 21 product targeted mainly for enterprise deployment? The vice versa view. Rather effort to use security configuration, vulnerability and patch management also in Fedora product(s) (provide necessary tools to allow it). The content itself will differ depending on the fact if it's used in enterprise-level or academic / personal-level (enterprise-level companies required their systems to meet the federal agencies standards for example etc.), but security hardening guides / tips are applicable to Fedora OS instances too (IOW you don't need to be an enterprise-level company to require / prefer system to be secured and have ways how to tune in various aspects of system's security). So this proposal is to provide such tools. Is OpenSCAP being retargeted for general purpose level infrastructure. Not sure it was ever dedicated / restricted to be enterprise-level only. From [3]: The Security Content Automation Protocol (SCAP), pronounced “ess-cap”, combines a number of open standards that are used to enumerate software flaws and configuration issues related to security ... It is a method for using those open standards for automated vulnerability management, measurement, and policy compliance evaluation. There's nothing about it being exclusive just to enterprise-level infrastructure (actually in contrast the open standards are highlighted couple of times above). Of course writing the content requires time resources. So it's more likely enterprise-companies will have dedicated funds to support content creation of their needs. But the standard itself (AFAICT) doesn't enforce / allows it to be used in enterprise-level infrastructure only. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? The answer depends how many Fedora users care about security of their Fedora systems and would be interested / willing to spend some time to harden it via the possibilities provided by this proposal. I'm looking at this from a different angle. Do we, out of the box in anaconda, have a spoke for configuring SELinux policy specifics (or downloading new policies)? Do we, out of the box in anaconda, have a spoke for setting the F21 crypto policy feature, or password encryption algorithms, or the firewall? I think a similar level works here - I see no issues with support of this in anaconda that's exposed in kickstart, or post-install support for easily applying a policy that an organization might have. But for the interactive install case, I think we're probably better served by just choosing secure defaults rather than having a specific screen in the installer for every user. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 06:25:03AM -0400, Jan Lieskovsky wrote: One hypothetical [*] scenario coming to my mind being the users might be willing to provide customized policy content to Fedora installation. Let's suppose the case there is a SCAP content for vulnerability checking (and ensuring some restrictions) for Fedora systems. Something like is done for Red Hat Enterprise Linux case: https://www.redhat.com/security/data/metrics/ This seems pretty niche. I am not sure how niche case this is or not. Was just an example when this might be desired. The cost associated with it is UI that makes no sense to most users but is presented to them by default anyway. I think we should concentrate on finding a way to make this possible without compromising the common case. Would making that spoke / field expandable upon click be sufficient? (though this might result into situation the feature would went completely unnoticed by some users, on the other hand wouldn't mean such big divergence from actual state) Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Jan Lieskovsky (jlies...@redhat.com) said: Is any Fedora 21 product targeted mainly for enterprise deployment? The vice versa view. Rather effort to use security configuration, vulnerability and patch management also in Fedora product(s) (provide necessary tools to allow it). The content itself will differ depending on the fact if it's used in enterprise-level or academic / personal-level (enterprise-level companies required their systems to meet the federal agencies standards for example etc.), but security hardening guides / tips are applicable to Fedora OS instances too (IOW you don't need to be an enterprise-level company to require / prefer system to be secured and have ways how to tune in various aspects of system's security). So this proposal is to provide such tools. Is OpenSCAP being retargeted for general purpose level infrastructure. Not sure it was ever dedicated / restricted to be enterprise-level only. From [3]: The Security Content Automation Protocol (SCAP), pronounced “ess-cap”, combines a number of open standards that are used to enumerate software flaws and configuration issues related to security ... It is a method for using those open standards for automated vulnerability management, measurement, and policy compliance evaluation. There's nothing about it being exclusive just to enterprise-level infrastructure (actually in contrast the open standards are highlighted couple of times above). Of course writing the content requires time resources. So it's more likely enterprise-companies will have dedicated funds to support content creation of their needs. But the standard itself (AFAICT) doesn't enforce / allows it to be used in enterprise-level infrastructure only. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? The answer depends how many Fedora users care about security of their Fedora systems and would be interested / willing to spend some time to harden it via the possibilities provided by this proposal. I'm looking at this from a different angle. Do we, out of the box in anaconda, have a spoke for configuring SELinux policy specifics (or downloading new policies)? Do we, out of the box in anaconda, have a spoke for setting the F21 crypto policy feature, or password encryption algorithms, or the firewall? No, we don't. But the proposal is here so we wouldn't need to have them in the future. Everything you listed above can be handled via SCAP rules / profiles. The only thing we need is an entry point required to have a chance somehow to signal users they should take a minute before actually hitting the Begin installation button to think about final security level (should it be SELinux policies, crypto policy, password encryption algorithms, firewall rules specification etc.) of the installed system, they would like the targeted installed system to have. I think a similar level works here - I see no issues with support of this in anaconda that's exposed in kickstart, or post-install support for easily applying a policy that an organization might have. But for the interactive install case, I think we're probably better served by just choosing secure defaults rather than having a specific screen in the installer for every user. Agree with secure defaults proposal. But the issue is it's wide term (what one user might consider secure enough for them [and it truly might be secure enough for their application / usage case of Fedora installation], might not seem as being sufficient enough to another user -- couple of examples: * how long passwords should the system require to allow newly created users to be registered? 8, 10, 12, 14 characters long? Even longer? * should the partitions be encrypted by default or not? * should /var, /var/log, /tmp be on separate partitions or not? (I think) the answers on these (and similar questions) can't be generalized to be the best ones for each of the systems. Of course it is possible to provide reasonable defaults against currently existing threats / attacks (to the level of actual knowledge), but there still is a risk of not hitting a group of possible users due that. Yet another view - in the current state we provide secure defaults that are reasonable enough for majority of the systems, but require / expect the users to get (and stay) informed about the development / evolution in the security area (meaning they need to know there exist such concept like disk encryption, and that they probably want to start using it. Let's another such feature be recent systemd's log file fingerprinting. And there are many aspects of the operating system evolving too quick to expect / require the users (each of them) to be aware of each of the new possibilities. In contrast to that compare a design in which the user could select just level of
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, 2014-03-14 at 11:22 -0400, Jan Lieskovsky wrote: On Fri, Mar 14, 2014 at 06:25:03AM -0400, Jan Lieskovsky wrote: One hypothetical [*] scenario coming to my mind being the users might be willing to provide customized policy content to Fedora installation. Let's suppose the case there is a SCAP content for vulnerability checking (and ensuring some restrictions) for Fedora systems. Something like is done for Red Hat Enterprise Linux case: https://www.redhat.com/security/data/metrics/ This seems pretty niche. I am not sure how niche case this is or not. Was just an example when this might be desired. The cost associated with it is UI that makes no sense to most users but is presented to them by default anyway. I think we should concentrate on finding a way to make this possible without compromising the common case. Would making that spoke / field expandable upon click be sufficient? (though this might result into situation the feature would went completely unnoticed by some users, on the other hand wouldn't mean such big divergence from actual state) I agree with Matt and Bill that this doesn't sound like something appropriate to display in the installer in the usual case, and I don't think that idea makes it any better (if anything it just pointlessly complicates the installer UI). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. I am afraid there isn't a default policy that would suit every possible use case Fedora OS can be used at. Yes, there's something like common understanding / agreement which technologies can be considered safe at current level of (security) knowledge (i.e. that certain cryptographic algorithms should be preferred for usage before the others etc.) But the current Fedora defaults approach has one limitation - even when we set up the defaults reasonable enough, there is possibility users can return back to the use of less secure ways (example how many users are still using telnet or rsh today?) If there isn't, how are we going to educate users as to which choice they should be making? We can do the following (three alternatives comes to mind): * use sane defaults, allow the less secure ones (if I am not wrong this is the current approach), * use and enforce sane defaults (prohibiting users from using the less secure ones). Not good since they might turn back, * use sane defaults, allow the less secure ones. But provide a way how to instruct users what should be the expected secure default today [*] (IOW having Anaconda to install the system to conform with some profile might instruct them to investigate why it was configured the way it was). Besides that there should be possibility to scan the system against the (by the security community) accepted defaults to indicate there's something wrong in the configuration of their system. The vision (maybe naive) being that this (having selected system properties / configurations marked wit red colour) could make them to think about the reasons of that state (and hopefully subsequently in the next stage make them to change these OS expectation patterns). *I* don't understand the terms used in the proposed UI, Can you be more concrete which term(s) you don't understand? Maybe you are right and the concept needs to be better explained / presented differently prior wider adoption [**]. so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [*] I am not speaking about the security of the default Fedora installation right now. Rather about the (possibly insecure) ways it can be (still) used (despite have sane defaults) [**] It has been designed by folks for which SCAP is daily bread, so it's possible it needs simplification (wider view) prior being able to be commonly accepted. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-14 16:03 GMT+01:00 Bill Nottingham nott...@splat.cc: I'm looking at this from a different angle. Do we, out of the box in anaconda, have a spoke for configuring SELinux policy specifics (or downloading new policies)? Do we, out of the box in anaconda, have a spoke for setting the F21 crypto policy feature, or password encryption algorithms, or the firewall? We don't, and I don't think we should. The experts in this area (combined with our testing of real-world usability) have much better chance to choose a suitable default than a random user that is an expert in something else than security. When choosing such a default, we *are*, though, limited to making choices that don't noticeably inconvenience the user and don't change their usual workflow, and that is a *fairly significant* limitation. There are two ways to avoid this limitation and get better security: either be a security expert or paranoid yourself (and in that case you don't need anaconda's handholding), or have an expert (that you trust or have to listen to) make an informed choice for you. Larger-scale security policies, the kind that would be verified using SCAP, are usually (if their usage is not just a cargo cult) the latter: a way to defer to an expert. For example, the policy may require longer passwords. Such a requirement could not be a general default, but the reasons why it can't be a general default doesn't apply to the institution imposing the non-default security policy, namely: - It would be based on an *informed* analysis of the threats and attacks applicable in that environment that calls for the longer value. - It would be *acceptable to impose* because within the institution having an inconveniently long password is being accepted as a part of people's jobs, not as a reason to give up on the OS and install Windows / use a tablet instead. - It would be *verifiably followed*--that's the primary technical function of SCAP. (... but note that this anaconda add-on would actually use SCAP to *modify* the configuration, not just* validate* it). I think a similar level works here - I see no issues with support of this in anaconda that's exposed in kickstart, or post-install support for easily applying a policy that an organization might have. The nice thing about during-install support is that it gives the policy writer/maintainer a really specific and static target: it's fairly easy to test that with the static installation environment and a known set of packages, the policy can be applied and results in full compliance. Then, immediately after installation, one could e.g. (yum update), and if that caused a policy violation, there would be a known starting point from which one could look for the cause of the violation. But for the interactive install case, I think we're probably better served by just choosing secure defaults rather than having a specific screen in the installer for every user. It seems to me that please input an URL for the policy to follow is not a reasonable interactive installation step. Having more than one policy, or policy profile, within the repository, and asking the user to choose (is this a server / wired workstation / laptop you will be taking out of the building) might be appropriate even for an interactive installation done by uninformed users--I don't know whether the proposed code supports this feature or even how desirable it would be. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-14 17:01 GMT+01:00 Jan Lieskovsky jlies...@redhat.com: Jan Lieskovsky (jlies...@redhat.com) said: I'm looking at this from a different angle. Do we, out of the box in anaconda, have a spoke for configuring SELinux policy specifics (or downloading new policies)? Do we, out of the box in anaconda, have a spoke for setting the F21 crypto policy feature, or password encryption algorithms, or the firewall? No, we don't. But the proposal is here so we wouldn't need to have them in the future. Everything you listed above can be handled via SCAP rules / profiles. The only thing we need is an entry point required to have a chance somehow to signal users they should take a minute before actually hitting the Begin installation button to think about final security level (should it be SELinux policies, crypto policy, password encryption algorithms, firewall rules specification etc.) of the installed system, they would like the targeted installed system to have. What *specific* question would they be asked? Certainly not think about security :) especially if they may be asked to input a URL. But for the interactive install case, I think we're probably better served by just choosing secure defaults rather than having a specific screen in the installer for every user. Agree with secure defaults proposal. But the issue is it's wide term (what one user might consider secure enough for them [and it truly might be secure enough for their application / usage case of Fedora installation], might not seem as being sufficient enough to another user -- couple of examples: * how long passwords should the system require to allow newly created users to be registered? 8, 10, 12, 14 characters long? Even longer? * should the partitions be encrypted by default or not? * should /var, /var/log, /tmp be on separate partitions or not? (I think) the answers on these (and similar questions) can't be generalized to be the best ones for each of the systems. I think we have a fairly good chance to choose a *general* default, at least in the abstract. For these specific examples: - Don't make workstation passwords long; it always annoys users and there's not a *real* need for a them to be long (well, except for the disk encryption password). Instead just disable remote access features (perhaps, even if enabling file sharing, only enable it with TTL=1 to avoid making it acessible to the Internet). - Yes if there is an interactive user. We *should* be just asking the users to log in, and use the login process to unlock the disk, thus making it completely transparent, instead of having a separate LUKS passphrase. - No, partitions are a lame workaround for quotas. If our quotas are lacking, let's enhance them. SCAP *is* useful precisely in the situations where a *general* default is not applicable--but those are pretty much by definition non-default situations; we wouldn't be giving the default user in a default installation environment a choice in security policies; see above about what question would you ask the user? Yet another view - in the current state we provide secure defaults that are reasonable enough for majority of the systems, but require / expect the users to get (and stay) informed about the development / evolution in the security area (meaning they need to know there exist such concept like disk encryption, and that they probably want to start using it. Fedora's lifetime is short enough that by the time such an evolution happens, the user will be reinstalling and therefore automatically using our new defaults. (The user might be using fedup and thus perhaps miss the defaults change, but this Change AFAICT doesn't apply to that case either.) In contrast to that compare a design in which the user could select just level of security they want the final system to meet [to simplify let's split them just into 1) low, 2) medium 3) high levels]. I'm afraid such one-dimensional measurement of security just doesn't work. If the high level caused ssh connections from an old computer, or TLS to their bank, to fail, how would they be told that they need to change from high to medium? How would the user know which one to choose? (How would they know that they shouldn't be choosing high in the first place because it would break TLS to their bank?) What if they really need ssh connections to work (because it's on the local network anyway) but want the TLS to their banks to be well-protected? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 12:38:59PM -0400, Jan Lieskovsky wrote: I am afraid there isn't a default policy that would suit every possible use case Fedora OS can be used at. Yes, there's something like common understanding / agreement which technologies can be considered safe at current level of (security) knowledge (i.e. that certain cryptographic algorithms should be preferred for usage before the others etc.) selinux doesn't suit every possible use case that Fedora supports either. But we still default to it being enabled with a targeted policy and provide no installer UI to let people change that. But the current Fedora defaults approach has one limitation - even when we set up the defaults reasonable enough, there is possibility users can return back to the use of less secure ways (example how many users are still using telnet or rsh today?) Well, yes. If you're deploying in an environment where you want to make it impossible for users to disable security features, you shouldn't be allowing those users to choose their own security policy. That's not an argument for putting it in the installer UI. If there isn't, how are we going to educate users as to which choice they should be making? We can do the following (three alternatives comes to mind): * use sane defaults, allow the less secure ones (if I am not wrong this is the current approach), Yes, a user can edit /etc/selinux/config to disable selinux. They can also modify the mmap_min_addr sysctl. But we don't offer those choices in the installer, because there's no way that most users are going to be able to make an informed decision about what these values should be set to or what the associated compromises are. *I* don't understand the terms used in the proposed UI, Can you be more concrete which term(s) you don't understand? Maybe you are right and the concept needs to be better explained / presented differently prior wider adoption [**]. What is a Data stream? What is a Checklist? How do I know which ones to pick? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. I'm all for creating a recommended hardening policy that users can opt into at install time. This feature would allow us to provide that kind of data to the end user. If the user decides to not implement a policy that would simply yield the same outcome as we have today. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI0z1AAoJEB/kgVGp2CYvpNML/0xKlHRNY4l7wFW80cl6GCb1 E4jVS17FZyeMKbd88WYpTvTtt6fQxGRAWb90B9FwAQD8WuTP6tOTWLmndbnby6qo grGvF29eClO9NQRzftLESH3uUPuJPfVBQhyGzDZNWkYSNKApf+hSGHBzPm7NcXi6 aE5F9fLCeE0NTCkeBD6xnzSdWwhsfBxKI4YScqkS+fbR8+m0+XP4sh74YkxPDo1p SqTA/qOWX6UZhq0YnXx37R94QjukGjXWL8uyQniyPZvGbnKIcXe0UC92M6HumOHN pLqJtMciKCnUYkDwUONXAWNB6bD2oIXg1V2XaGK5y9FzwSTs7J2tZY61/18R3nCY pXEtLWHVSvfHRudB1c4wpR09zDDb1p/ZXQ9dk4/JzzkUuxewlAXVgLFWw39De/lJ RdATsLMUxUwhsrDF1+UlVLYEbC+coLkGzyGD1VcQYnOeHPyIWJ4sQ317L0oxZSB7 TWMJbx7oSx6HXgFgzLWK4EqbuOokecVZCVwlTQyFfQ== =KsuO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. Right now there is just one policy. In there future there could be several. I could see a server specific, workstation specific, virt specific, PCI, USGCB, STIG, common criteria, etc. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:51:10PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. Right now there is just one policy. In there future there could be several. I could see a server specific, workstation specific, virt specific, PCI, USGCB, STIG, common criteria, etc. Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:51:10PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. Right now there is just one policy. In there future there could be several. I could see a server specific, workstation specific, virt specific, PCI, USGCB, STIG, common criteria, etc. Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 12:38:59PM -0400, Jan Lieskovsky wrote: On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote: I disagree with this assessment. The workstation is exactly where much of these hardening needs to take place. I can't see an installation that wouldn't benefit from this feature. If there's a default policy that would make sense for most workstation users, we should just make that the default. I am afraid there isn't a default policy that would suit every possible use case Fedora OS can be used at. Yes, there's something like common understanding / agreement which technologies can be considered safe at current level of (security) knowledge (i.e. that certain cryptographic algorithms should be preferred for usage before the others etc.) While I agree with this we can make some obvious suggestions to users. (See below WRT defaults.) If there isn't, how are we going to educate users as to which choice they should be making? We can do the following (three alternatives comes to mind): * use sane defaults, allow the less secure ones (if I am not wrong this is the current approach), Yeah, this doesn't happen. Defaults generally allow dumb things to happen in the name of interoperability (someone might be still using IE 2). I'll point to the default setup of GnuPG as a perfect example. It defaults to SHA-1 signatures instead of SHA-2. If someone is still running a version of PGP, OpenPGP, or GnuPG that doesn't currently support SHA-2 then you really need to upgrade (there are vulnerabilities in your version!). I note SHA-1 signatures on most everyone's message in spite of the known weaknesses and advice to now use a SHA-2 hash. * use and enforce sane defaults (prohibiting users from using the less secure ones). Not good since they might turn back, I like prohibiting dumb things from happening but then things that JustWork(TM) will start to break since they haven't been updated since 2005. :) - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI1HcAAoJEB/kgVGp2CYvK5oL/27RKwMmt3SPx8MgX1Y/6qr3 AufUJ1PP7L9Jn/WQyePsUrANlkJQ3QYG2OA5ar4NXODbOKvgLSCXcToeL5qQR3CJ Pq0GW0wMG0waVwVLca0V7aixwRy27+860eLre49GMwpCsrQt+1AFpW0FV7gnXYbp Xjq67k41P8zqoGyDlOg564Z4NmtS4lpxpDDJ8Nym2e4DnkaMmGOCjXJpGI7K9A6x mSJzDIn/pfE6iFYWuV7/AM1yAD2RBYlPifnzHaMvU2d/bR+d1eQBUXiSiV4nN4Ks xgcL//DpDPeeInT+KUKrZ5EFtazTLcKk/Wk131WwUbIXSsFduOZKflUbIOUVWYMp 4X9lkAw6qahD/Ktn7/4ZONvUH3pTPnwaJzmzSlJXT4uwXOzxK1MMb4vK4jdDj4ux X8ZstWg20Q7Ys4GOoU/AWPCs0Vqm4w9nU6gi/g86VFBV1DruDaFitADgQkkR49Ij yfG+hhaeWPwUTQ3M6BJBO7i2cpbGRvMalVNdPjhisA== =isNX -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 06:59:18PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI1MbAAoJEB/kgVGp2CYvO8oL/06v8nf4qVt9oOrfBJeNdAn1 xK1ptfZVN/4JnWR9W1TYzOdl2S3ZUJS/IqQTHXrdBoD69Me6QkSja1Punm9eirom oRofZxz1Z8rU/tZHVbKznq3TW8+KUVpcTyI0f6FxXEtWBnh1QlZjm5Kgh8PMAcGv fRXJ601YKo4JgGJMd9JzQqepU2Xr/CkyIkTGHqTwFVRPq9DnSj8XA8NsnjzSwBmD EMXpi4dtpTDug+k7K/Tg/QRZ1tY/iCHCTVz3x75dNM4sZ1bV1qihbvXryffKRBhu qGhQUF0xFd5RpuL1DPkjHJ65v2VCjGsODz0KkqgZ7aH7A57sTyV+RNke+LwvZRrx H4Z14i5h1HLqD7d80NfmBiYLUtal5yWjs5zvGlLD4SROvKwtB7W1QlrDBFq26c+A MnmIx5sczRriSnOE+9H3ROQw4DctEW7ksUbPLFAbdrqM1SxRSkvqz/us2+03vbfp jSRR3cSbFDkt/7tPoh3LgV9MtH4AlG/C6ZMM6n4tRg== =OvQ7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. I'm all for creating a recommended hardening policy that users can opt into at install time. This feature would allow us to provide that kind of data to the end user. If the user decides to not implement a policy that would simply yield the same outcome as we have today. How does the average user make an informed decision about whether an available security policy is appropriate for them? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:06:06PM -0400, Eric H. Christensen wrote: You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I'm making the assumption that you, as someone with sufficient knowledge of the field to make an informed choice, are capable of performing additional steps in order to ensure that your system meets additional security criteria. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. It's not going to be a massive change? It's an entire additional spoke in the UI. That *is* a massive change. Users will click on it. Users will be confused by it. They'll choose inappropriate options and then complain that their software doesn't work, and then they'll either take resources from our limited support pool or give up and install something else instead. The job of the installer is to make it as easy as possible for the user to end up with a working system. Adding options that make it straightforward for the user to end up with a non-working system is a backwards step. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Miloslav Trmač (m...@volny.cz) said: There are two ways to avoid this limitation and get better security: either be a security expert or paranoid yourself (and in that case you don't need anaconda's handholding), or have an expert (that you trust or have to listen to) make an informed choice for you. Sure. Leaving out the first case (IMO, those that can write their own SCAP policy know how to apply it), let's look at the second. By deferring to an expert, you're saying that the end user does not know enough to make a coherent decision on the individual points. This works in a larger-scale enterprise use, because those users are expected to just defer to the corporate policy where someone has decided what sort of machine you have, and what the expected policy for that is. Now take the general case of all interactive installs. If we accept that the end user, in general, does not have the expertise to decide on the details of the security policy, how does exposing it in the installer in this way help? You'd need a much more clearly defined description of the policies, delination of them by use cases, and so on - speak to the user in terms that they understand. Having it done by URLs (hey, are we checking the ceritficate on that https server?), or by a low/medium/high distinction doesn't appear to be the right paradigm. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. I'm all for creating a recommended hardening policy that users can opt into at install time. This feature would allow us to provide that kind of data to the end user. If the user decides to not implement a policy that would simply yield the same outcome as we have today. How does the average user make an informed decision about whether an available security policy is appropriate for them? I guess we'll have to describe the different policies and provide approprate documentation/education. You know, pretty much how we get users to understand whether or not they should encrypt their hard drives or assign the first user as an administrator or anything else they do with their computer. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI1toAAoJEB/kgVGp2CYvLdYMAJUf/CAbyUyBjG7OyGnymibW blV7gzgp6F9lXAQ5s6ZfLV9AMO18uwJc3icK5Hv8JmLfROkdfyRL3OfOnNS8Py3H OI0y2dHFXAVhjb/OF6Yr9Pxyippbhdc2kDfDCJrJrwbIPdTzD+h1UfWvBRdngAEq BYqJDXbsSZfzCoQAWfzz2Ow4AZ1xVcJqcgPTfmbcY1DsYeww9d9Bm4Csh14r6BFB na7nFX6fEVU+vlyvNmtgPVvKvmxM8KpaCRWS+mu6rmzqwDQwsL7pRGsrBngL1VKD CrKxm9vi4JqKadhBE9kUv0OEbFYRz0LXkginfWIEjiIbK4gw5tfRNy42yHFASYsC 5v6tIynpeM4J3cOfEkTI/aps1g6Y3cvx1HqCHrCe4a38sqNjaDJqkNjF3V8E+N1M OCYUR84LpnQ1rpGuhTpfF0pXsD4iEZ0qHygf9/DyEbYxhI8Jb7dijRAXILdn36gH zS02B541zZCfOmvkNGOoJIPUwElWB8ykpfeepeCeyg== =q61C -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote: How does the average user make an informed decision about whether an available security policy is appropriate for them? I guess we'll have to describe the different policies and provide approprate documentation/education. You know, pretty much how we get users to understand whether or not they should encrypt their hard drives or assign the first user as an administrator or anything else they do with their computer. The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Am 14.03.2014 20:31, schrieb Matthew Garrett: On Fri, Mar 14, 2014 at 02:39:51PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 03:00:20PM +, Matthew Garrett wrote: If there's a default policy that would make sense for most workstation users, we should just make that the default. If there isn't, how are we going to educate users as to which choice they should be making? *I* don't understand the terms used in the proposed UI, so I'd be willing to put money on the number of potential users who do being pretty close to statistically indistinguishable from 0. I'm all for creating a recommended hardening policy that users can opt into at install time. This feature would allow us to provide that kind of data to the end user. If the user decides to not implement a policy that would simply yield the same outcome as we have today. How does the average user make an informed decision about whether an available security policy is appropriate for them? why is only the average user relevant? how do usesers get advanced? by notice things which sounds interesting, ignore them the first time, use Google and doing the same again no longer skip things my whole IT education and anything i am doing in ym current job for the last 11 years was learnt that way - by doing and *while* doing read details, but first it needs a start signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-14 20:41 GMT+01:00 Bill Nottingham nott...@splat.cc: Now take the general case of all interactive installs. If we accept that the end user, in general, does not have the expertise to decide on the details of the security policy, how does exposing it in the installer in this way help? You'd need a much more clearly defined description of the policies, delination of them by use cases, and so on - speak to the user in terms that they understand. Having it done by URLs (hey, are we checking the ceritficate on that https server?), or by a low/medium/high distinction doesn't appear to be the right paradigm. I agree; my earlier mail contained what I think might be reasonable end-user choices to expose. But that's essentially talking about the site using a modified repo, not a vanilla Fedora. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-14 20:47 GMT+01:00 Reindl Harald h.rei...@thelounge.net: why is only the average user relevant? how do usesers get advanced? by notice things which sounds interesting, ignore them the first time, use Google and doing the same again no longer skip things Offering the user to use one of the pre-defined SCAP policies during installation does not educate them much--all they learn is the names of the pre-defined policies. *Reading and modifying* the policies would very likely be a great way to learn, but that definitely shouldn't happen within the installer. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 08:51:08PM +0100, Miloslav Trmač wrote: 2014-03-14 20:47 GMT+01:00 Reindl Harald h.rei...@thelounge.net: why is only the average user relevant? how do usesers get advanced? by notice things which sounds interesting, ignore them the first time, use Google and doing the same again no longer skip things Offering the user to use one of the pre-defined SCAP policies during installation does not educate them much--all they learn is the names of the pre-defined policies. *Reading and modifying* the policies would very likely be a great way to learn, but that definitely shouldn't happen within the installer. Correct, but they could create their own policies and import them into the installer, thus making it easier to use Fedora. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI164AAoJEB/kgVGp2CYvzHQL/i5QVSsrwNdtXOGHE+yp4q3l VEjTybYsmyCYyhxOiRZuZhHwvRQXL8QG6V+2LSedrNCwSB5B5h5Zm1hcn/8t4bXH Vto6YrsxX/7+KWjRlP6OolMVjIzaq+lswzzPPqDR5vsb1/lSEQQc/ycm1UdnXPMz GaHqoaAc6BYY9vUfBYgi0nx+Hl0vB56jNbtDNJFWv83JZOiJf/Lkde9X+DFzvpaS wwHhva/lTY40CiC/PX/lSWYtfv/RZu6v1xqmaamfFMWmxakc2NwOKfRxRrvekLe5 pmUvKsIy6SfpHP42UUXSfAeb08gmjmVtX1TPZ2/Myb/ITWeh4ELomeNreh77xoy7 3rAkB0aQyq9ISjGcrL5w1xjroXxZOybNVYKAB5QtcnM7HpY9Qh6L/YisBCNvgHUv ChrElYaMhvm+yOiwXLrV76UvqPKBak3sqo5PUMJvRmMAv8ZBj57rwBf0Fpmcyf5l Iu1TsTg2fSIASy8tDOczyMz0hN4ZP33Q1LUCLbI/wg== =xXqL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote: How does the average user make an informed decision about whether an available security policy is appropriate for them? I guess we'll have to describe the different policies and provide approprate documentation/education. You know, pretty much how we get users to understand whether or not they should encrypt their hard drives or assign the first user as an administrator or anything else they do with their computer. The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. What exactly do you think would be done with one of these policies? You seem to think that an incorrect choice will brick a system. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI179AAoJEB/kgVGp2CYvtCgMAI9d9tKv/KcUm4gcMKh2kKuo rwxY5G4hY5x5pyFJJILU+b6dLp1Yes6nHB8PLnA2Oy3hg3+ikxK5Vd1jisui5bzo NbB1Pylgzs/2o4dke/xGUqkZwQqR/G69WEMhfR/Ki7sRL5KmG8DIF7MuPr1lx//y A415IfBq+52DozXJd/l2xHNI/YMgCugylBVhMC4ypG/KlPDQ4PTKb4qpVsP+Lf/G i/108AKMRjskrdTKHxteVatPVQG+S8vQWXcVYTHt69+NzBiYfG514fvgqul6phz/ X0X/003kPkAw2R2U7zQ2FDoyXN6e9ko3NAJouNd+SaI8fpzux+uevYx06fTGpwoc m1756XjAC1LTfHp42lPgJjskexRo53Yu76ZrJZVbSjknnuR7aHQKtHNKLIgDY2Wn h+FvvPE2tx6DcPEiItb3ZAd4Y1Zyx93LeGYnsgIl8uEMM5QcRvK/KC2g1smX37tp 4CfjA7EAdXE480esFJn1/GHfV8IKL1n7gWuX4EpFiQ== =2+tr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Am 14.03.2014 20:51, schrieb Miloslav Trmač: 2014-03-14 20:47 GMT+01:00 Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net: why is only the average user relevant? how do usesers get advanced? by notice things which sounds interesting, ignore them the first time, use Google and doing the same again no longer skip things Offering the user to use one of the pre-defined SCAP policies during installation does not educate them much—all they learn is the names of the pre-defined policies. /Reading and modifying/ the policies would very likely be a great way to learn, but that definitely shouldn't happen within the installer. only mention the pure existence and lead to the one or another after the install types SCAP policies in Google would be a gain - that is how you make people interested a few years ago i also did not know the word SCAP until i tried to setup a security scanner for our internal network (OpenVAS) and so i learned all my current advanced knowledge by plug such random pieces faced here and there together and finally started working in the IT and cintuned to learn every single day signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote: The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. What exactly do you think would be done with one of these policies? You seem to think that an incorrect choice will brick a system. If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On 14 March 2014 13:45, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Mar 14, 2014 at 03:41:30PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:31:55PM +, Matthew Garrett wrote: How does the average user make an informed decision about whether an available security policy is appropriate for them? I guess we'll have to describe the different policies and provide approprate documentation/education. You know, pretty much how we get users to understand whether or not they should encrypt their hard drives or assign the first user as an administrator or anything else they do with their computer. The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. Actually the failure mode of the wrong choice on the encrypted partition is usually the system is now a brick because the person has forgotten the password, mistyped the password, made the password different etc. It is no different from the mass of people who forget their user password or root password except the system is completely unusable and can't be recovered. [I say this because it is the most common one I have had to deal with encrypted laptops in the field.] I am not saying that putting a choice for security options in the anaconda is a good idea myself. It is just yet another brick my box option we have and I would only want to see it in a Show me options which are dangerous mode. I am saying that we have a lot of shoot myself in the foot options already and Encrypted Partition is higher on the list than people know. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 08:01:53PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote: The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. What exactly do you think would be done with one of these policies? You seem to think that an incorrect choice will brick a system. If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. No, that's not exactly it. I've pointed out reasons why defaults usually suck (security-wise). I've yet to see a hardened system make software fail. I'd love some examples of your concerns. I also don't understand why FIPS compliance will make a user have a bad time since I've been on systems that were fully FIPS compliant and didn't have any problems. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI4GhAAoJEB/kgVGp2CYv2mAL/2DUh90PebxuUFwfPVVrRCUE gHVuzpFnxtXltHsKtTJvCOG2X7I51bzmeHx482BtUMk91UriRGO9+1bchfWuHPdq iv77DJuYciAOU5qKWvAalO6KS3lmZnTfpOZgnlaf2Bg+YndCRNHqbbLhAwP1F4bb 0cA1HgfgkdlNyTc/szYhP1WjWxuNXp4qKhXTELqhnMNaHkQTVaqgmW20iP0TmGqu wxHGhgPEykeqPbgj2AAWRHKIcfx/Js5ojtcpSkvavhxjUsWFJyh4RzZXBaaQTRLb RXKs9T0cEdat7xVgzXsiSQwIiGS0X1Wv3wtxLMHZWLwUCXbumaLtwT/JjMZWbkN2 k3ofasxkIddCiXIypCF+svmbB9Gh9bxyQCtVUAXgrX6V0gwqpayWl40dmPEhZzsi YHOR/Tdy10SAOhYCBli4mgbwCFsK8es7BE1pZgZ2haz6FhAbRosDxmPwvbfpfahD 0OCMCwdv4a8+eBWTsThHhWbU7EA5UaG0BeHHEFHH+A== =TMcN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Mar 14, 2014, at 1:06 PM, Eric H. Christensen spa...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 06:59:18PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I think Matthew is making a reasonable assumption that many (probably even most) other users will become confused to the point of being disturbed by something that seems to require their attention, has a UI with terms they aren't likely familiar with, while suggesting choices, yet at the moment there's only one policy (?) so why is a UI needed for this right now? This is usually what kickstart installs are for. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. At this point it doesn't appear to need a UI. There's no off or on switch, or opt in or opt out. There's one policy. I'd say even with three policies available I'm much better off with a slider that says Standard Security - More Secure - Most Secure. I mean, that's sufficiently dumbed down I still don't know what those things actually mean in terms of policy or behaviors, but relative to each other I've made a more informed decision than what I'm currently presented with. I mean honestly how complicated does an OS install need to be? It's like piling on the user. It does need a default, like Timezone spoke, even though sometimes that too is set wrong for a particular user. The default avoids the requirement the user enter the spoke. It should be a minimum recommended security policy. The next question I have is how this spoke can affect other spokes, as well as affect the installation process itself? What I'm looking for is some assessment of impact on QA resources needed to test this feature, if any resources are needed at all. If there's no default but the user must interact with this spoke to proceed with installation, that's definitely a QA impact. There's maybe one or two toothbrush wrappers of spare resources in QA (and I'm already imagining Adam feverishly writing a reply, UMMM, I don't think so, where?!) So if it's even remotely possible for a security policy to be chosen that later causes some sort of install, or even a first boot failure to happen - that's too much QA impact right now, short of a recruitment drive. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On 14 March 2014 16:24, Eric H. Christensen spa...@fedoraproject.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 08:01:53PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 03:56:47PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 07:45:53PM +, Matthew Garrett wrote: The failure mode of making the wrong choice regarding an encrypted partition or the default user being an administrator involves the system *continuing to work*. The failure mode of making the wrong choice regarding security policy is that things you expect to work mysteriously don't. What exactly do you think would be done with one of these policies? You seem to think that an incorrect choice will brick a system. If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. No, that's not exactly it. I've pointed out reasons why defaults usually suck (security-wise). I've yet to see a hardened system make software fail. I'd love some examples of your concerns. I also don't understand why FIPS compliance will make a user have a bad time since I've been on systems that were fully FIPS compliant and didn't have any problems. You need to do more technical support :). FIPS compliance can break all kinds of software because it limits what algorithms you can use and various software will be configured to use MD5 or some other algorithm which isn't FIPS allowed. This shows up a lot in certain environments where they are mandated to run a program from 2001 and also be FIPS compliant. [Or the http certificate is signed with a cert that uses MD5 or some other key.] I have also had enough users who have run BASTILLE and turned everything on and then have very unusable systems because the box has now no network, no approved logins, no X and is only listening on a serial port which does not exist on the hardware. [This is not a dig at Bastille and other scripts. They can be used to set up for specific security plans if you know what you are doing.. if not you are using an atomic bomb to hunt voles in your garden.] I have to help people who have to run government mandated scanners on their networks but do things that make selinux even in permissive mode stop stuff. [Symantec back in 2008 from my email.] Let us just say a lot can be broken depending on what the security policy is you are setting things to. Most of the time it is going to be stuff we don't ship or control.. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Fri, Mar 14, 2014 at 06:24:36PM -0400, Eric H. Christensen wrote: On Fri, Mar 14, 2014 at 08:01:53PM +, Matthew Garrett wrote: If an incorrect choice means that the software the user wants to run won't run, that's going to be a problem for the user. And we presumably expect that some software won't run, because otherwise we'd be enabling that security feature by default? A user who accidentally installs a profile that enables FIPS compliance is going to have a bad time, for instance. No, that's not exactly it. I've pointed out reasons why defaults usually suck (security-wise). I've yet to see a hardened system make software fail. I'd love some examples of your concerns. I also don't understand why FIPS compliance will make a user have a bad time since I've been on systems that were fully FIPS compliant and didn't have any problems. You don't think it would upset users to have their kernel panic if they accidentally tried to load an inappropriately signed module? What happens if I ssh to a server that doesn't implement any of the FIPS-approved algorithms? Why is Firefox suddenly asking for a password before I can visit https sites? Why won't Firefox speak https to a bunch of sites? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 04:25:48PM -0600, Chris Murphy wrote: On Mar 14, 2014, at 1:06 PM, Eric H. Christensen spa...@fedoraproject.org wrote: On Fri, Mar 14, 2014 at 06:59:18PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I think Matthew is making a reasonable assumption that many (probably even most) other users will become confused to the point of being disturbed by something that seems to require their attention, has a UI with terms they aren't likely familiar with, while suggesting choices, yet at the moment there's only one policy (?) so why is a UI needed for this right now? Today there are three policies. Tomorrow there will likely be many more. I can name off probably a dozen policies that might be useful. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. At this point it doesn't appear to need a UI. There's no off or on switch, or opt in or opt out. There's one policy. I'd say even with three policies available I'm much better off with a slider that says Standard Security - More Secure - Most Secure. I mean, that's sufficiently dumbed down I still don't know what those things actually mean in terms of policy or behaviors, but relative to each other I've made a more informed decision than what I'm currently presented with. I mean honestly how complicated does an OS install need to be? It's like piling on the user. Because it's much more than None - More - Most. This tool can configure a system in many different ways to meet a policy. It does need a default, like Timezone spoke, even though sometimes that too is set wrong for a particular user. The default avoids the requirement the user enter the spoke. It should be a minimum recommended security policy. Right, there are things in anaconda that do not require me to make any selection right now. This policy selection should be similar (the visual markups that I've already seen seemed to show this being optional). Only venturing inside will the user be presented with a choice where I suspect None will also be an option. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTI4enAAoJEB/kgVGp2CYveMAL/17K2PwhrvMc7kdRaL8n65qv 6UM9cp9LrbKd/Ah8ZQFuSBdgWor+cdDQhB3GRDa/dnT5qsZAtSCCnHXbMVNseRcR QgU66JIgwoUMkSdQ7tSM9CRLf8enXgbqY1qYRguVnRL7I7AihMu9xX29PCd+ws6q sNlAmSPLUZZ2znGDWTcTmt8FJavt5NQD0+DadLy0PL1v6YpOxtHyoc9Y1/4L6xY+ t014QFWuHKlIagGzLLYHZeUsyNx4yXaI3VVfTbIkqyVEQ5F/bbvFhmHSScUXf4I5 CI+RTb5MzC0WrATMz8v2hoeUDdYzUb3jwH2OpQnwepoYUZ0+u5GCurWpNkDTENDI CPLkMcUyh86s5LTyi1pP2+ExblFb59FUe9fVZs+LPIAqgWeEE2Hocx7Mkt5xAlI+ b9vljj++GdE0xTEzckX66XNFVPgIHW1zD/UTvLVGRE9qIUtewuYnNY5y/B0Vu78j kyz14zToCMQZh15o6xjoXzfoi2/LGrzoBV0sjfVkGg== =ULWV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-13 11:29 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? == Scope == * Release engineering: Few simple changes... your village pedant A Change with a Release Engineering section is unlikely to be self-contained /your village pedant Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system (e.g server rules for the server WG, cloud rules for the cloud WG etc.). Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team == Scope == * Release engineering: Few simple changes... your village pedant A Change with a Release Engineering section is unlikely to be self-contained /your village pedant Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
2014-03-13 12:47 GMT+01:00 Jan Lieskovsky jlies...@redhat.com: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
How would this alter the default user installation experience? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 15:27 +0100, Vratislav Podzimek wrote: On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. Will the spoke's label have some text like No security profile selected or somesuch when that's the case? Presumably the Begin Installation is insensitive until the Security Profile spoke is happy, like how other spokes work? I like the overall idea, but I'm slightly nervous about the UI. How, if at all, do security policies affect the UI in the *other* spokes? (sorry, I wasn't able to view your videos on this box, just the screenshots). For example, if you have a security profile which mandates that /tmp be on a separate partition or logical volume, does this affect the UI in the partitioning spoke? Similarly, if the profile forbids package telnet from being installed, does this show up somehow in the Software Selection spoke? (e.g. what if the user tries to manually select telnet within that spoke?). Likewise, does the Profile's password complexity requirements affect the password UI? Or is it a case of: review the issues listed in the Security Profile spoke, and figure out how do I fix this?, switch to the appropriate spoke, try to fix it, see if the Security Profile spoke is now happy, else repeat. That seems suboptimal, though what you've got may well be good enough for a first iteration (and I'm not volunteering to hack on it, so feel free to ignore me ;) ). Hope this is constructive; as I said, I like the proposal. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
How would this alter the default user installation experience? Please have a look at the demo images / videos available at: https://fedorahosted.org/oscap-anaconda-addon/wiki/Demos Basically there would be one SECURITY section added (with SECURITY PROFILE subsection) into the Anaconda's installation summary screen. In that section user will be able to configure the further details wrt to intended / desired security policy to be applied. Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. I can remember seeing some video from Vratislav demonstrating the 'fetch security policy in RPM format remotely' scenario too, but you are right it's not illustrated in those demos (yet). Vratislav, can you add demo video of this use case too? Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [*] At the moment only HTTP / FTP options are allowed, but AFAIK there's support for more protocols planned. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, Mar 13, 2014 at 02:45:58PM -0400, Jan Lieskovsky wrote: The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. Ok. I'm kind of struggling to imagine the scenario where a user actually wants to do that. What's the use-case for providing UI rather than limiting deployment to Kickstart? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 14:45 -0400, Jan Lieskovsky wrote: On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. The SCAP Security Guide content is loaded automatically (if available) and even when user clicks the Change content button, there is again the Use SCAP Security Guide button that gives them SSG back. Otherwise fetching data stream collection (XML), archive (zip or tarball) or RPM is supported so far. Other protocols and format types may be added in the future based on user feedback and requests. I can remember seeing some video from Vratislav demonstrating the 'fetch security policy in RPM format remotely' scenario too, but you are right it's not illustrated in those demos (yet). Vratislav, can you add demo video of this use case too? The RPM support is demonstrated in the following video preview: http://vpodzime.fedorapeople.org/oaa-0.4-changes.webm However, I see that a new commented video preview would explain a lot of common questions appearing in this discussion, so I'll record one tomorrow and post it here and on the feature page. Thanks for the useful and constructive feedback, guys! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Mar 13, 2014 at 04:40:01PM -0600, Chris Murphy wrote: Existing NIST and Red Hat documentation on OpenSCAP says that it's for enterprise-level Linux infrastructure. Is any Fedora 21 product targeted mainly for enterprise deployment? Is OpenSCAP being retargeted for general purpose level infrastructure. If so, will (or should) at least a significant minority, say 33%, of GUI installer using end-users make use of this feature? Coming from someone who used to have to configure systems to meet DISA STIG requirements I applaud this feature. One can use the same SCAP rules to audit their system later to look for changes in the system. Looking beyond the existing offerings of NIST-specific compliance, one can write their own rules for configuring their systems at install. I wouldn't look at this feature to only be useful for enterprise-level installations but rather flexible enough for any installation. What does setting a security profile in Anaconda achieve that can't be done, or done as effectively, post-install? You could have similar results using a kickstart file or some sort of script post-install but you'd end up duplicating the work to create the rules for install and auditing. I won't comment on the ease of using one over the other. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTIk7vAAoJEB/kgVGp2CYvs78L/0Ft+nmGsaeiY6KZEDuwXFyL bEk3hOsPs/HkQvRz3BXfLHnKuy1P7tptVXIjzrWmiAU/uWrMpBPo2a79mQAvbJDR V9PqfSF7xTbXt5m6wfvDwgMoqn1bF3lrmC9s+fZYQi2UGjR820swUdoB+TJnmPVt E68Ty8I1Eeeeh92JOZrh26hUcyvVEqo7iuV8RtRsjkwEHi/PiUYmOloOoLoYprOW 0vkcd4u+rDwp8Wl+NoElL48Q/i1m5lt5gLTxBn1m22vw9H9Y3/vMcrLMXQlNMS0W c1xdOLeWlUdfN0imtiy9kw8mPl9urZw7PcVX4x3BcQlm4Hs8nWG27t1pL1uQGbuF EnvsnK7q1wTUIusv9uDmJAphDulljEq1BYEXmfZjvS+6tcx8zD4i9PG7Q5JsyWbZ FhHmKMgg6xCA8GUN4AEYEAUHFR86kgqAGaaGOL7J+oA5i9JT++/pWEae+eNjcskw Y84/kexmFSd0mHqwHaMtKEVRVdkwmxdcnoA0YvGMHA== =8Xoo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
