From s.a.w.vanderknijff at student.hhs.nl Fri Dec 7 11:01:17 2007 From: s.a.w.vanderknijff at student.hhs.nl (Knijff, S.A.W. van der) Date: Fri, 07 Dec 2007 12:01:17 +0100 Subject: Research: effects of diversity on threads from malware Message-ID: I'm performing an research about the effects of diversity on malware. In this research there will be looked at the effects of diversity within an operating system on malware, in this case different GNU/Linux distro's. Cause of the limited time schedule there will only be tested with three distro's, after this there will be picked one distro which is tested on different architectures. There is chosen to work with Fedora Core 6, OpenSuse 10.2 and Ubuntu 6.10. Before starting the real-life tests there is a need to make some assumptions on what will happen when the malware is run on a system. Here for there will be looked at the compiler flags that are used during compilation of the distribution, I'm namely interested in the compiler flags which enhance the security within the distro. Also are there any kind of security measurements besides the compiler flags, for example SELinux, AppArmor, Address Randomization Execshield, PIE or others? I hope that you can provide me with some answers on my questions so i can move on with the research. Stephan From sundaram at fedoraproject.org Fri Dec 7 11:33:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Dec 2007 17:03:21 +0530 Subject: Research: effects of diversity on threads from malware In-Reply-To: References: Message-ID: <47592F81.5070502@fedoraproject.org> Knijff, S.A.W. van der wrote: > I'm performing an research about the effects of diversity > on malware. In this research there will be looked at the > effects of diversity within an operating system on malware, > in this case different GNU/Linux distro's. > Cause of the limited time schedule there will only be > tested with three distro's, after this there will be picked > one distro which is tested on different architectures. > There is chosen to work with Fedora Core 6, OpenSuse 10.2 > and Ubuntu 6.10. > Before starting the real-life tests there is a need to make > some assumptions on what will happen when the malware is > run on a system. Here for there will be looked at the > compiler flags that are used during compilation of the > distribution, I'm namely interested in the compiler flags > which enhance the security within the distro. > Also are there any kind of security measurements besides > the compiler flags, for example SELinux, AppArmor, Address > Randomization Execshield, PIE or others? > I hope that you can provide me with some answers on my > questions so i can move on with the research. Refer http://fedoraproject.org/wiki/Security/Features Rahul From maximilian_bianco at yahoo.com Sat Dec 8 03:54:58 2007 From: maximilian_bianco at yahoo.com (Maximilian Bianco) Date: Fri, 7 Dec 2007 19:54:58 -0800 (PST) Subject: Research: effects of diversity on threads from malware In-Reply-To: Message-ID: <220309.19462.qm@web62308.mail.re1.yahoo.com> Would you care to expand on the methods you will be using for testing. Careful consideration must be given to the methodology employed so that unbiased results are produced. Happy Holidays, Max --- "Knijff, S.A.W. van der" wrote: > I'm performing an research about the effects of > diversity > on malware. In this research there will be looked at > the > effects of diversity within an operating system on > malware, > in this case different GNU/Linux distro's. > Cause of the limited time schedule there will only > be > tested with three distro's, after this there will be > picked > one distro which is tested on different > architectures. > There is chosen to work with Fedora Core 6, OpenSuse > 10.2 > and Ubuntu 6.10. > Before starting the real-life tests there is a need > to make > some assumptions on what will happen when the > malware is > run on a system. Here for there will be looked at > the > compiler flags that are used during compilation of > the > distribution, I'm namely interested in the compiler > flags > which enhance the security within the distro. > Also are there any kind of security measurements > besides > the compiler flags, for example SELinux, AppArmor, > Address > Randomization Execshield, PIE or others? > I hope that you can provide me with some answers on > my > questions so i can move on with the research. > > Stephan > > -- > Fedora-security-list mailing list > Fedora-security-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-security-list > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From bugzilla at redhat.com Sun Dec 9 14:08:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 9 Dec 2007 09:08:26 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200712091408.lB9E8Q2Y027668@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Alias: CVE-2007-0095 https://bugzilla.redhat.com/show_bug.cgi?id=221694 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|devel |rawhide ------- Additional Comments From redhat-bugzilla at linuxnetz.de 2007-12-09 09:08 EST ------- Created an attachment (id=282211) --> (https://bugzilla.redhat.com/attachment.cgi?id=282211&action=view) Proposal of a possible fix for CVE-2007-0095 Can somebody please review this patch carefully, because upstream seems not to be interested to solve this issue at all. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Dec 10 20:44:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 10 Dec 2007 15:44:52 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200712102044.lBAKiqRI004663@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Alias: CVE-2007-0095 https://bugzilla.redhat.com/show_bug.cgi?id=221694 updates at fedoraproject.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |ERRATA Fixed In Version| |2.11.3-1.fc7 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Dec 10 20:47:05 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 10 Dec 2007 15:47:05 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200712102047.lBAKl58j016407@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Alias: CVE-2007-0095 https://bugzilla.redhat.com/show_bug.cgi?id=221694 ------- Additional Comments From updates at fedoraproject.org 2007-12-10 15:47 EST ------- phpMyAdmin-2.11.3-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Dec 10 20:44:47 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 10 Dec 2007 15:44:47 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200712102044.lBAKilFP015441@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Alias: CVE-2007-0095 https://bugzilla.redhat.com/show_bug.cgi?id=221694 ------- Additional Comments From updates at fedoraproject.org 2007-12-10 15:44 EST ------- phpMyAdmin-2.11.3-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Dec 19 10:52:31 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 19 Dec 2007 05:52:31 -0500 Subject: [Bug 357051] CVE-2007-5712 Django 0.96 i18n DoS In-Reply-To: Message-ID: <200712191052.lBJAqV0n019953@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-5712 Django 0.96 i18n DoS Alias: CVE-2007-5712 https://bugzilla.redhat.com/show_bug.cgi?id=357051 Bug 357051 depends on bug 362761, which changed state. Bug 362761 Summary: CVE-2007-5712 Django 0.96 i18n DoS [F7] https://bugzilla.redhat.com/show_bug.cgi?id=362761 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CURRENTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Dec 20 11:59:30 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 20 Dec 2007 06:59:30 -0500 Subject: [Bug 367471] CVE-2007-5197: mono Math.BigInteger buffer overflow In-Reply-To: Message-ID: <200712201159.lBKBxUYv029956@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-5197: mono Math.BigInteger buffer overflow Alias: CVE-2007-5197 https://bugzilla.redhat.com/show_bug.cgi?id=367471 Bug 367471 depends on bug 367531, which changed state. Bug 367531 Summary: CVE-2007-5197: mono Math.BigInteger buffer overflow [f7] https://bugzilla.redhat.com/show_bug.cgi?id=367531 What |Old Value |New Value ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution| |ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Dec 20 12:00:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 20 Dec 2007 07:00:26 -0500 Subject: [Bug 367471] CVE-2007-5197: mono Math.BigInteger buffer overflow In-Reply-To: Message-ID: <200712201200.lBKC0QOe030572@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-5197: mono Math.BigInteger buffer overflow Alias: CVE-2007-5197 https://bugzilla.redhat.com/show_bug.cgi?id=367471 Bug 367471 depends on bug 367571, which changed state. Bug 367571 Summary: CVE-2007-5197: mono Math.BigInteger buffer overflow [fc6] https://bugzilla.redhat.com/show_bug.cgi?id=367571 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Dec 20 12:01:35 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 20 Dec 2007 07:01:35 -0500 Subject: [Bug 367471] CVE-2007-5197: mono Math.BigInteger buffer overflow In-Reply-To: Message-ID: <200712201201.lBKC1ZHZ003612@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-5197: mono Math.BigInteger buffer overflow Alias: CVE-2007-5197 https://bugzilla.redhat.com/show_bug.cgi?id=367471 thoger at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |ERRATA ------- Additional Comments From thoger at redhat.com 2007-12-20 07:01 EST ------- Fedora updates: https://admin.fedoraproject.org/updates/F7/FEDORA-2007-3130 https://admin.fedoraproject.org/updates/F8/FEDORA-2007-2969 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From riley.marquis at tcsresearch.org Fri Dec 21 03:29:29 2007 From: riley.marquis at tcsresearch.org (riley.marquis at tcsresearch.org) Date: Thu, 20 Dec 2007 19:29:29 -0800 (PST) Subject: Security Changes For Fedora 9 Message-ID: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Security Updates For Fedora 9 Greetings! I had several ideas for Fedora 9 in regards to improving the security of a default installation. 1: Disable root account / Use Sudo 2: /etc/ssh/sshd_config changes -PermitRootLogin no (currently 'yes') -LoginGraceTime 1m (currently 2m) -Banner /etc/issue.net (currently not set) -AllowGroups wheel (currently not set) We should also see if the OpenSSH developers would be willing to make these changes the default on Portable OpenSSH. 3: Add wheel group if not present If there is no wheel group by default, we should include one in Fedora 9. This means deciding on what Group ID (GID) to use. Anaconda would need to force creation of a user account that is a part of this group. 4: GCC Lockdowns With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access? 5: Bastille Be sure to incorporate the most important Bastille fixes (www.bastille-linux.org). This project appears to have stalled and requires an older version of Fedora to run, unless you're a Perl ninja =) Maybe we should contact the developer (Jay Beale), and ask him what he needs to revive the project? Perhaps the Fedora community can be of assistance. 6: Make Packages for PortSentry & LogCheck Can we add PortSentry & LogCheck to the list of available Fedora Packages? I know the project appears to have stalled since late 2003. 7: Password Protect Single User Mode (Runlevel 1) 8: USB Key Authentication / Dual Factor Authentication Should we use PGP or another tool to allow people to login/logout with a USB drive? This would have to work for KDE and Gnome at the very least, and while we are at it, we might as well support XFCE. Inserting/Removing the USB drive could automatically login/logout the user, with or without a password as a second form of authentication, depending on how Joe Admin wants his security set up. 9: Can we include TrueCrypt as a new package, provided it meets the requirements, such as having an open source license, no patents or copyrights, etc? Hope these ideas prove useful to the community. Regards, Riley F. Marquis III Senior Analyst - TCS Research From Christian.Iseli at licr.org Fri Dec 21 08:17:35 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 21 Dec 2007 09:17:35 +0100 Subject: Security Changes For Fedora 9 In-Reply-To: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Message-ID: <20071221091735.2ef18f58@ludwig-alpha.unil.ch> On Thu, 20 Dec 2007 19:29:29 -0800 (PST), riley.marquis at tcsresearch.org wrote: > With the new GCC-4.3.0 recently built for Fedora 9, we should forbid > ordinary users access to the programs it contains, incl. rpmbuild, > mock, etc. Only members of the wheel, koji, and mock groups should > have access to software development tools. Did I miss any groups > that should be allowed access? Yikes! We want to encourage people to develop software, not prevent them... That's the whole idea behind free/open-source! Christian From tmraz at redhat.com Fri Dec 21 12:20:24 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 21 Dec 2007 13:20:24 +0100 Subject: Security Changes For Fedora 9 In-Reply-To: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Message-ID: <1198239624.12586.101.camel@vespa.frost.loc> On Thu, 2007-12-20 at 19:29 -0800, riley.marquis at tcsresearch.org wrote: > Security Updates For Fedora 9 > > Greetings! > I had several ideas for Fedora 9 in regards to improving the security of a > default installation. > > 1: Disable root account / Use Sudo Maybe more secure from one point of view maybe less secure from another. So please no. > 2: /etc/ssh/sshd_config changes > -PermitRootLogin no (currently 'yes') Not before we have a way how to login on remotely installed vnc machine. > -LoginGraceTime 1m (currently 2m) If upstream changes it then yes. > -Banner /etc/issue.net (currently not set) sshd doesn't support escape sequences which are currently present in issue.net > -AllowGroups wheel (currently not set) No. > We should also see if the OpenSSH developers would be willing to make > these changes the default on Portable OpenSSH. They wouldn't except perhaps the LoginGraceTime change. > 3: Add wheel group if not present > If there is no wheel group by default, we should include one in Fedora 9. > This means deciding on what Group ID (GID) to use. Anaconda would need to > force creation of a user account that is a part of this group. There is a wheel group by default with root as a member. > 4: GCC Lockdowns > With the new GCC-4.3.0 recently built for Fedora 9, we should forbid > ordinary users access to the programs it contains, incl. rpmbuild, mock, > etc. Only members of the wheel, koji, and mock groups should have access > to software development tools. Did I miss any groups that should be > allowed access? Nonsense. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From maximilian_bianco at yahoo.com Fri Dec 21 15:53:19 2007 From: maximilian_bianco at yahoo.com (Mr.Scrooge) Date: Fri, 21 Dec 2007 07:53:19 -0800 (PST) Subject: Security Changes For Fedora 9 In-Reply-To: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Message-ID: <318208.46371.qm@web62312.mail.re1.yahoo.com> Personally i like being able to log in as root when necessary. This way i don't have to worry about a mis-configured sudoers file. I am still a little green when it comes to the security subject but I think its important for new users to know about the root account and the dangers involved. The advanced users will be able to set things up the way you suggest without any trouble but a new user might be a little bewildered by the whole thing. Distros like Ubuntu setup the first user as admin/root if i am not mistaken, Apple takes the same approach i think though i don't know the particulars of the two setups, it makes me nervous. Feel free to educate me. -Max --- riley.marquis at tcsresearch.org wrote: > Security Updates For Fedora 9 > > Greetings! > I had several ideas for Fedora 9 in regards to improving the security of a > default installation. > > 1: Disable root account / Use Sudo > > 2: /etc/ssh/sshd_config changes > -PermitRootLogin no (currently 'yes') > -LoginGraceTime 1m (currently 2m) > -Banner /etc/issue.net (currently not set) > -AllowGroups wheel (currently not set) > > We should also see if the OpenSSH developers would be willing to make > these changes the default on Portable OpenSSH. > > 3: Add wheel group if not present > If there is no wheel group by default, we should include one in Fedora 9. > This means deciding on what Group ID (GID) to use. Anaconda would need to > force creation of a user account that is a part of this group. > > 4: GCC Lockdowns > With the new GCC-4.3.0 recently built for Fedora 9, we should forbid > ordinary users access to the programs it contains, incl. rpmbuild, mock, > etc. Only members of the wheel, koji, and mock groups should have access > to software development tools. Did I miss any groups that should be > allowed access? > > 5: Bastille > Be sure to incorporate the most important Bastille fixes > (www.bastille-linux.org). This project appears to have stalled and > requires an older version of Fedora to run, unless you're a Perl ninja =) > Maybe we should contact the developer (Jay Beale), and ask him what he > needs to revive the project? Perhaps the Fedora community can be of > assistance. > > 6: Make Packages for PortSentry & LogCheck > Can we add PortSentry & LogCheck to the list of available Fedora Packages? > I know the project appears to have stalled since late 2003. > > 7: Password Protect Single User Mode (Runlevel 1) > > 8: USB Key Authentication / Dual Factor Authentication > Should we use PGP or another tool to allow people to login/logout with a > USB drive? > This would have to work for KDE and Gnome at the very least, and while we > are at it, we might as well support XFCE. Inserting/Removing the USB > drive could automatically login/logout the user, with or without a > password as a second form of authentication, depending on how Joe Admin > wants his security set up. > > 9: Can we include TrueCrypt as a new package, provided it meets the > requirements, such as having an open source license, no patents or > copyrights, etc? > > > Hope these ideas prove useful to the community. > > Regards, > Riley F. Marquis III > Senior Analyst - TCS Research > > > -- > Fedora-security-list mailing list > Fedora-security-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-security-list > ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From kevin at tummy.com Fri Dec 21 17:13:21 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 21 Dec 2007 10:13:21 -0700 Subject: Security Changes For Fedora 9 In-Reply-To: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Message-ID: <20071221101321.1fd1d3aa@ghistelwchlohm.scrye.com> On Thu, 20 Dec 2007 19:29:29 -0800 (PST) riley.marquis at tcsresearch.org wrote: > Security Updates For Fedora 9 > > Greetings! Greetings. > I had several ideas for Fedora 9 in regards to improving the security > of a default installation. > > 1: Disable root account / Use Sudo There are tradeoffs here. I personally would like to see it continue to be enabled until we can figure out more of the issues around disabling it. ...snipp... > 4: GCC Lockdowns > With the new GCC-4.3.0 recently built for Fedora 9, we should forbid > ordinary users access to the programs it contains, incl. rpmbuild, > mock, etc. Only members of the wheel, koji, and mock groups should > have access to software development tools. Did I miss any groups > that should be allowed access? I would also say this is a bad idea. We want people to use the tools on the machine, don't we? > 5: Bastille > Be sure to incorporate the most important Bastille fixes > (www.bastille-linux.org). This project appears to have stalled and > requires an older version of Fedora to run, unless you're a Perl > ninja =) Maybe we should contact the developer (Jay Beale), and ask > him what he needs to revive the project? Perhaps the Fedora > community can be of assistance. We should take a look I agree, but many of the things bastille did/does are not useful these days. Disabling rsh/rlogin? Disabling compilers (your point 4 I guess)? Setting more agressive security defaults on some applications? Many of the things it does we should be doing in the packages we ship, not trying to modify after install. Would anyone be interested in culling through and coming up with a list of items we should address that bastille does? > 6: Make Packages for PortSentry & LogCheck > Can we add PortSentry & LogCheck to the list of available Fedora > Packages? I know the project appears to have stalled since late 2003. Personally, I don't find portsentry usefull anymore. The number of port scans that go on anymore means I don't want to hear about blocking specific IP's. I just want everything except specific services blocked by default. There's nothing preventing someone from submitting packages for fedora however... > 7: Password Protect Single User Mode (Runlevel 1) Might be worth doing. I think the reason it hasn't in the past is that there haven't been good international ways of querying for passwords. With encrypted root and instantX this might be worth looking at. > 8: USB Key Authentication / Dual Factor Authentication > Should we use PGP or another tool to allow people to login/logout > with a USB drive? > This would have to work for KDE and Gnome at the very least, and > while we are at it, we might as well support XFCE. > Inserting/Removing the USB drive could automatically login/logout the > user, with or without a password as a second form of authentication, > depending on how Joe Admin wants his security set up. You can already do that with smartcards. Just allowing someone to login with a hardware token seems a bad idea. All someone would need is the usb drive. > 9: Can we include TrueCrypt as a new package, provided it meets the > requirements, such as having an open source license, no patents or > copyrights, etc? Not possible for fedora. I don't know if the license is acceptable, but it has a kernel module. Fedora doesnt allow kernel modules. Perhaps it could be added to the livna repo? > > Hope these ideas prove useful to the community. You bet... thanks for the input... > Regards, > Riley F. Marquis III > Senior Analyst - TCS Research kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Dec 21 17:15:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Dec 2007 11:15:37 -0600 Subject: Security Changes For Fedora 9 In-Reply-To: <20071221101321.1fd1d3aa@ghistelwchlohm.scrye.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <20071221101321.1fd1d3aa@ghistelwchlohm.scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: >> 7: Password Protect Single User Mode (Runlevel 1) KF> Might be worth doing. That's what the grub password is for. - J< From bjorn.sund at it.uib.no Sat Dec 22 17:42:38 2007 From: bjorn.sund at it.uib.no (Bj=?ISO-8859-1?B?+A==?=rn Tore Sund) Date: Sat, 22 Dec 2007 18:42:38 +0100 Subject: Security Changes For Fedora 9 In-Reply-To: <20071222170019.2B527731B3@hormel.redhat.com> Message-ID: On 22/12/07 18:00, "fedora-security-list-request at redhat.com" wrote: > Message: 1 > Date: Fri, 21 Dec 2007 10:13:21 -0700 > From: Kevin Fenzi > Subject: Re: Security Changes For Fedora 9 > To: fedora-security-list at redhat.com > Message-ID: <20071221101321.1fd1d3aa at ghistelwchlohm.scrye.com> > Content-Type: text/plain; charset="us-ascii" > > On Thu, 20 Dec 2007 19:29:29 -0800 (PST) > riley.marquis at tcsresearch.org wrote: > >> Security Updates For Fedora 9 >> >> Greetings! > > Greetings. Greetings, indeed. >> 1: Disable root account / Use Sudo > > There are tradeoffs here. I personally would like to see it continue to > be enabled until we can figure out more of the issues around disabling > it. As long as enabling root is as simple as setting a root password or some other simple and automatable procedure I don't care. But for large scale remote administration you need direct root access via key-based ssh. >> 4: GCC Lockdowns >> With the new GCC-4.3.0 recently built for Fedora 9, we should forbid >> ordinary users access to the programs it contains, incl. rpmbuild, >> mock, etc. Only members of the wheel, koji, and mock groups should >> have access to software development tools. Did I miss any groups >> that should be allowed access? > > I would also say this is a bad idea. We want people to use the tools on > the machine, don't we? We do indeed. In general, limiting access to tools which don't affect the system you're working on causes issues. There are always users arguing for root access or against centralised admin setups, often the very users who shouldn't have any sort of access to anything. Limiting access to stuff simply because it can be done is one of the things that triggers them, and the more tools this happens to the more likely it is that someone will forget to open up what should have been open in the first place. Bj?rn -- Bj?rn Tore Sund Phone: 555-84894 Email: bjorn.sund at it.uib.no IT department VIP: 81724 Support: http://bs.uib.no Univ. of Bergen When in fear and when in doubt, run in circles, scream and shout. From metcalfegreg at qwest.net Sat Dec 22 21:31:52 2007 From: metcalfegreg at qwest.net (Greg Metcalfe) Date: Sat, 22 Dec 2007 13:31:52 -0800 Subject: Security Changes For Fedora 9 In-Reply-To: <20071221101321.1fd1d3aa@ghistelwchlohm.scrye.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <20071221101321.1fd1d3aa@ghistelwchlohm.scrye.com> Message-ID: <200712221331.53139.metcalfegreg@qwest.net> On Friday 21 December 2007 09:13:21 am Kevin Fenzi wrote: > > 5: Bastille > > Be sure to incorporate the most important Bastille fixes > > (www.bastille-linux.org). This project appears to have stalled and > > requires an older version of Fedora to run, unless you're a Perl > > ninja =) Maybe we should contact the developer (Jay Beale), and ask > > him what he needs to revive the project? Perhaps the Fedora > > community can be of assistance. > Since 2000 or so I, or people I know, have found the Bastille project stalled for a platform that it needed to be evaluated against, on at least three occasions. Pulling it up on rpmfind.net, the last changelog entry reads: * Sun Apr 16 2006 Jay Beale 3.0.9-1.0 - Added support for Fedora Core 5 - Added support for SUSE 10.0 - Added support for Mandrake 10.0, 10.1, 2006... - Added support for OS X Tiger (10.4) - preliminary > We should take a look I agree, but many of the things bastille did/does > are not useful these days. Disabling rsh/rlogin? Disabling compilers > (your point 4 I guess)? Setting more agressive security defaults on > some applications? Many of the things it does we should be doing in the > packages we ship, not trying to modify after install. > Usefulness depends upon what you're doing. For instance, Bastille was supported on HP-UX, though I no longer know how well. I've seen one environment where not only were the Berkeley 'r' programs were still used very heavily, but also rusers, in which case the portmapper had to be accessible. Granted, this is the sort of thing that applies mostly to non-GUI, often headless, installs. This is probably not a typical environment for Fedora, but one that definitely does happen, and with some frequency. > Would anyone be interested in culling through and coming up with a list > of items we should address that bastille does? > That would require someone who's running a distro that's pretty old. If I still had a SuSE 10.0 or FC5 box, I'd have already run Bastille in evaluation mode, just to see where it was a couple of years ago. If enough people want to see the information, I'd be willing to load FC5 on a box, on a temporary basis, after the holidays. I could also run it from the source tarball on more recent Fedoras, again in eval mode, just for some comparison data. Be advised that working alone, it could take me a couple of weeks to produce all the data. Time is somewhat limited. I've not looked at the code in some time, so I don't know if I'd have to run it against, say, a minimal, GNOME, and KDE install for each version. Also, not being familiar with the current code, it could be full of security or other bugs. The bz2 tarball is 312 KB. That's a fair amount of Perl, which may not have received a plethora of eyeballs, and I've no idea what (if any) test harnesses may have been used, etc. If there's a lot of demand for the information, hopefully someone will also come forward to split the testing load with me. If not, I can live with that, and run everything by mid-January. Actually, I'd *have* to complete it by then, and I can't offer even a cursory code review. Someone may want to take a look at the requires and provides list for some hints about that. This is down to time issues that are beyond my control. My window runs from 1/2/07 through 1/14/07, inclusive. Sorry, folks, but it's the best I can do. I have to admit that I'm not sanguine about receiving an adequate return on investment from Bastille. The periodic halts in the project could mean a fair commitment of resources to avoid future problems. I've also heard stories from people who were able to run it, but found major problems in the ability of typical end users to use it correctly. Overall quality of code is also a huge unknown. That said, I'm not wedded to my opinion. This is just my two cents. Actual data is always preferable, if the community decides to seriously explore this. Not knowing exactly how to define that, as I don't know the size of this community, I'm making an arbitrary call that if a dozen people ask me to do it, I will. If any one person volunteers to split the load, I'll do it. I should probably look for list archives, and grep around for unique posters, just to get an idea of community size. But not today. Last-minute Christmas shopping is the higher priority. Jingle bells, and best wishes, Greg