csi-devel

csi-devel@lists.fedorahosted.org

18 discussions

Fudcon blacksberg
by Kevin Fenzi 15 Dec '11

15 Dec '11

Greetings. Is there any interest in doing a hackfest on CSI docs during fudcon? I'm sure I will be busy, but can plan a bit of time if other folks would like to sit down and work on the docs. ;) kevin

2 1

[csi] Fixed tags to allow publishing
by Eric Christensen 25 Oct '11

25 Oct '11

commit d21e18d07cb2fb84abca450fa4646d0bf5be27d0 Author: Eric 'Sparks' Christensen <sparks(a)fedoraproject.org> Date: Mon Oct 24 22:35:58 2011 -0400 Fixed tags to allow publishing security-policy/publican.cfg | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/security-policy/publican.cfg b/security-policy/publican.cfg index 5a42fad..5efdb9d 100644 --- a/security-policy/publican.cfg +++ b/security-policy/publican.cfg @@ -5,3 +5,5 @@ xml_lang: en-US type: Book brand: common +version: 1 +web_version_label: UNUSED

1 0

CSI Security Policy
by Eric Christensen 05 Oct '11

05 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings. Kevin asked me to take a look at the CSI Security Policy (I believe it was recently tweaked). I have a few questions that I'd like to ask in +hopes that I will learn and maybe we'll add some more good information to the policy. First, in section 2.2 the policy discusses host general security. All of this information relates specifically to IPv4 settings. Now I don't +have a good enough understanding of all the possibilities in sysctl but I know that ip6tables can be similarly configured for IPv6 networks. +Now it should be said that if you don't have IPv6 deployed that all IPv6 paths should be shut down and tools turned off to avoid utilizing +anything that may open up a path, unexpectantly, into the system. But if you are utilizing IPv6 we shouldn't forget about these paths and +should harden our systems against their misuse. Perhaps someone could help me with the sysctl stuff? Next, in the incident response I see there are great plans for safeguarding the evidence after an incident has occurred. I would like to +caution that one person's way of obtaining the information is not the next person's way of doing so. I'd like to see specific commands to be +run, that the drive is mounted as read-only while obtaining the images, and what safeguarding needs to occur with these images and what the +procedure is, for the hard drive, once an image has been obtained. Also, should we talk about remote authentication methods that should be used (ssh keys (RSA or DSA)(bit strength), encryption standards to be +used while transmitting data, what data should be stored encrypted and how should that be done, etc. I know how we (Fedora) does it now but +others that might look at this guide for... guidance... would probably want to know this information. My thought is that we should document +stuff that we are doing now even if it seems common sense. This is really some good stuff in that guide and I'd like to see even more technical information and technical explaination so we can continue +to be leaders in how things should be done in FLOSS community. - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJOinnVAAoJEIB2q94CS7PRquAQANaqQaCnU5RymhqauCq0p5nF xfrJR1WQbh0AigxBhBCh0HxmPToOLoBINvv57Emg23D7bkh/gMWzpPVzuIzPCrrh tIbEMHnXyNuhsSWYpBJakRHXEsAtwZZlZeSaxwtV/RM6egygphnO5lcYu/ckiUbx HYuVL9lPhxiytiH3vs+a3cG79TuB/XocIM+4xv743sTxY0CrbKcwXZwX7xWcLGvo PZrKkcf+4uOAUdZWXq2z5AE1acaTrXjHzaTrQPpordDC58ynDR07GvEoD0QQfk8B hz6TQR/BFyhuWPwkY9/lO3JiIlH5QuzAxYQeSz6IJZwgmPAC94Hbg+QbG7BoxkIV 9YZ4AXo3IMw20zATZElGxNcUQ9TrocRgyauLkYRPv6V1FygU+NI6hW02Ta8QtdX+ 06Vq+wCT6OV8m+1H18Adx2mPxHzw1jLiJKYZd5Yyh1WOjBMOLM7yJxq8i5TzRvqV IdJL0HLmS5QeNQC4+nbzQkhfW7f5LMx6/sn8W05TH8zsd0HzOGVn3bpeQPhgSTZK SCRxPBHb9BNTpDtOg70nMW/gQgftdvDlsiOyfkpIxDadzigpRMoYeuT4ML2zmCia TDLWJe6ESSbAnJ7JsPnVPHR6fyytYHMaMEZLrF2Va1vHc6ZbGjd2qCtdwzgGKv96 MI6TOM9DzXiqZTKrs1/k =JBZT -----END PGP SIGNATURE-----

2 1

[PATCH] various tweaks and updates for CSI doc
by Kevin Fenzi 23 Sep '11

23 Sep '11

Here's a patch with some fixes and updates to the Fedora CSI doc... comments or questions welcome! kevin -- diff --git a/security-policy/en-US/Author_Group.xml b/security-policy/en-US/Author_Group.xml index 2903efa..b76c94f 100644 --- a/security-policy/en-US/Author_Group.xml +++ b/security-policy/en-US/Author_Group.xml @@ -13,5 +13,14 @@ </affiliation> <email>mmcgrath(a)redhat.com</email> </author> + <author> + <firstname>Kevin</firstname> + <surname>Fenzi</surname> + <affiliation> + <orgname>Fedora Project</orgname> + <orgdiv>Infrastructure</orgdiv> + </affiliation> + <email>kfenzi(a)redhat.com</email> + </author> </authorgroup> diff --git a/security-policy/en-US/Book_Info.xml b/security-policy/en-US/Book_Info.xml index 1d7548a..85120f6 100644 --- a/security-policy/en-US/Book_Info.xml +++ b/security-policy/en-US/Book_Info.xml @@ -7,7 +7,7 @@ <title>security-policy</title> <subtitle>Information Technology Security Policies</subtitle> <productname>Documentation</productname> - <productnumber>0.2</productnumber> + <productnumber>0.3</productnumber> <edition>1</edition> <pubsnumber>1</pubsnumber> <abstract> diff --git a/security-policy/en-US/Revision_History.xml b/security-policy/en-US/Revision_History.xml index 35c65f4..9356721 100644 --- a/security-policy/en-US/Revision_History.xml +++ b/security-policy/en-US/Revision_History.xml @@ -21,6 +21,20 @@ </simplelist> </revdescription> </revision> + <revision> + <revnumber>2</revnumber> + <date>Fri Sep 22 2011</date> + <author> + <firstname>Kevin</firstname> + <surname>Fenzi</surname> + <email>kfenzi(a)redhat.com</email> + </author> + <revdescription> + <simplelist> + <member>Cleaned up links and names and added content.</member> + </simplelist> + </revdescription> + </revision> </revhistory> </simpara> </appendix> diff --git a/security-policy/en-US/enduser-standard.xml b/security-policy/en-US/enduser-standard.xml index 99fadac..755e236 100644 --- a/security-policy/en-US/enduser-standard.xml +++ b/security-policy/en-US/enduser-standard.xml @@ -66,6 +66,12 @@ </seglistitem> <seglistitem> <seg></seg> + <seg>Should</seg> + <seg>ssh known hosts</seg> + <seg>When using ssh to access machines, the ssh host key for the host should be checked against the canon version at: https://admin.fedoraproject.org/ssh_known_hosts.</seg> + </seglistitem> + <seglistitem> + <seg></seg> <seg>Must</seg> <seg>Desktop Locking</seg> <seg>Any time you physically leave your workstation or any other host that contains a user input or output device such as a keyboard, mouse, or monitor, either lock the screen or shell, or log out completely.</seg> @@ -74,7 +80,7 @@ <seg></seg> <seg>Should Not</seg> <seg>Password Reuse</seg> - <seg>Avoid reusing passwords in environments where there is not a single sign on capability. This is especially important in the case of password protected keys, encrypted shares, access to sensitive personal sites such as banking or other finances, and so on. Always maintain different passwords wherever possible.</seg> + <seg>Avoid reusing passwords in environments where there is not a single sign on capability. This is especially important in the case of password protected keys, encrypted shares, access to sensitive personal sites such as banking or other finances, and so on. Always maintain different passwords wherever possible. Password storage applications can be used to assist as long as the passphrase to open the application is a strong one.</seg> </seglistitem> <seglistitem> <seg></seg> @@ -112,6 +118,18 @@ <seg>Stolen or Missing Equipment</seg> <seg>Any stolen or missing equpment containing any sensitive data including passwords or keys, whether encrypted or not, must be reported as quickly as possible. When handled expediently, issues due to missing equipment can be easily mitigated.</seg> </seglistitem> + <seglistitem> + <seg></seg> + <seg>Should</seg> + <seg>selinux</seg> + <seg>Wherever possible, users should run their workstation in selinux "enforcing" mode.</seg> + </seglistitem> + <seglistitem> + <seg></seg> + <seg>Should</seg> + <seg>Updates</seg> + <seg>Updates should be applied in a timely manner to workstations. When security updates that fix severe vulnerabilities are available, they should be applied as soon as possible.</seg> + </seglistitem> </segmentedlist> </para> <section id="EndUser-Standard-Admin-Exceptions"> diff --git a/security-policy/en-US/security-policy.ent b/security-policy/en-US/security-policy.ent index 5ab9b2f..d8dae67 100644 --- a/security-policy/en-US/security-policy.ent +++ b/security-policy/en-US/security-policy.ent @@ -1,6 +1,6 @@ <!ENTITY PRODUCT "Community Services Infrastructure"> <!ENTITY BOOKID "security-policy"> -<!ENTITY YEAR "2009"> +<!ENTITY YEAR "2011"> <!ENTITY HOLDER "The Fedora Project"> <!ENTITY PUBLIC-RELATIONS-DELEGATE "fpl(a)fedoraproject.org"> <!ENTITY ORGANIZATION-NAME "The Fedora Project"> @@ -8,5 +8,5 @@ <!ENTITY SECURITY-TEAM-DELEGATE "admin fedoraproject.org"> <!ENTITY CHIEF-SECURITY-OFFICER "admin fedoraproject.org"> <!ENTITY CHIEF-INFORMATION-OFFICER "admin fedoraproject.org"> -<!ENTITY HELPDESK-ADDRESS "fedora-infrastructure-list(a)redhat.com"> +<!ENTITY HELPDESK-ADDRESS "infrastructuret(a)lists.fedoraproject.org"> <!ENTITY SECURITY-POLICY-URL "http://infrastructure.fedoraproject.org/csi/security-policy/">

1 0

[PATCH] Remove duplicate syncookies line.
by Jan-Frode Myklebust 01 Apr '09

01 Apr '09

Setting net.ipv4.tcp_syncookies once is probably enough. --- en-US/Books/SecurityPolicy/configs/sysctl.conf | 1 - en-US/Books/SecurityPolicy/standard.xml | 1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/en-US/Books/SecurityPolicy/configs/sysctl.conf b/en-US/Books/SecurityPolicy/configs/sysctl.conf index 1eacd70..ee9b318 100644 --- a/en-US/Books/SecurityPolicy/configs/sysctl.conf +++ b/en-US/Books/SecurityPolicy/configs/sysctl.conf @@ -41,7 +41,6 @@ net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 -net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.accept_source_route = 0 diff --git a/en-US/Books/SecurityPolicy/standard.xml b/en-US/Books/SecurityPolicy/standard.xml index 5d4835a..c5fc9f2 100644 --- a/en-US/Books/SecurityPolicy/standard.xml +++ b/en-US/Books/SecurityPolicy/standard.xml @@ -219,7 +219,6 @@ net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 -net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.accept_source_route = 0 -- 1.5.5.6

2 1

CSI Security Policy rollout
by Mike McGrath 30 Jan '09

30 Jan '09

Just letting people on the list know we've adopted the security policy doc in CSI in Fedora. I'll continue to post our Fedora CSI docs here: http://infrastructure.fedoraproject.org/csi/ I'm not totally happy with the completeness of the doc right now, but its certainly a good start. -Mike

1 0

Inventory Management
by Mike McGrath 24 Oct '08

24 Oct '08

Hey guys, what are you using for inventory management? Just a spreadsheet? Multiple spreadsheets? Anyone using smolt? :) -Mike

3 2

Re: Inventory Management
by Michael Stahnke 24 Oct '08

24 Oct '08

We use home-grown stuff. I'd like to fork what I have written here and someday open source it, but until the 36 hour day is invented, I'll probably fail at that. stahnma

1 0

Checkup
by Mike McGrath 26 Sep '08

26 Sep '08

Hey guys, so we still don't have any 'finished' books but I thought I'd check in to see what you all think about the format of the thing by now. I'm a really big fan of the checklist stuff we're doing in some of the standards but cross checklisting has become a concern of mine. I've been re-thinking the view here and am starting to wonder if we should focus more on the audience and less on the technology. For example, while writing the end user security policy I wanted to reference some of the information in the openssh book. The problem I'm running into is keep it modular but also in a way that makes sense. I looked at including sections in one book in another and got an error, there may be a way to overcome that, not sure. What are your thoughts? -Mike

1 0

Iptables standards and configuration management
by Stephen John Smoogen 04 Sep '08

04 Sep '08

One of the items that I have to deal with at UNM is a long list of different firewalls and servers. I have Solaris(9,10), AIX(various), MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9) to worry about with lots of different firewall needs for each one. As I am trying to standardize the firewalls... I run into that same headache everyone runs into at some point or another... How does one organize the various different firewalls in both the VCS and the upcoming configuration management system... while perfect is the enemy of the good.. what is a good way of doing it as I see way to many ways of laying it out in file structure. firewalls/project/OS/system project/firewall/OS/system OS/firewall/project/system OS/system/project/firewall etc etc etc. with some other // items added. Any ideas? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

csi-devel