Re: Security testing: need for a security policy, and a security-critical package process
On Monday 30 November 2009 22:40:07 Hal Murray wrote: g...@czarc.net said: ... A written description of the security policy is a must! ... Is the idea of a single one-size-fits-all security policy reasonable? I think Fedora has a broad range of users. No. Initially, I recommend one security policy and one reference implementation to test against. Each variation needs its own security policy and reference implementation definition. Later ones are easier to create because they can use the early ones as guidance. So, why go through all of this paperwork and bureaucratic bullshit? Well, those of us who have done this before believe that it is necessary. I do not like the bureaucratic BS any more than anyone else but, if you do not do it, then you are not quite sure what you have when you say that something meets security requirements. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Monday 30 November 2009 18:16:50 Adam Williamson wrote: On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote: Gene, (Ahh... someone with a similar background...) So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's Guide to the Secure Configuration of Red Hat Enterprise Linux 5 very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense. Thanks for the thoughts, Gene and Eric. You seem to be running a long way ahead here :). I should probably say that I think I mistitled the thread: what I was really thinking about here is not 'security', but the more limited area of 'privilege escalation'. I'm not sure we're ready to bite off a comprehensive distro-wide security policy yet, to the extent you two are discussing. But, you did say the right words for what is needed to do security QA and not just privilege escalation. Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges. Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do. I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tuesday 01 December 2009 13:56:51 Adam Williamson wrote: On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo. Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH. What you are saying put more emphasis on getting a security policy written and ratified by FESco. And you will also need some oversight of what the developers are doing with respect to security and this security policy. The QA process should catch the oops problems ... not those done intentionally by a well-intentioned developer. I do not know that much about PolicyKit and given my interests in security, I probably need to learn about it. One thing that occurs to me is to wonder if PolicyKit is using SELinux (see SELinux Users and Roles). If not, why not? Regardless of how PolicyKit works, the default should be locked-down with an easy-to-use sysadmin tool to provide configuration with the ability to open- things-up in a controlled manner. You should talk to the folks handling SELinux. My impression of them is that they know what they are doing and may provide some insight into the PolicyKit problem. Fedora has come a long way since SELinux was first introduced. It would be a shame if the enhanced security provided by SELinux was negated by PolicyKit. A couple of other comments: - No, I do not believe that regular users should be able to update or install software globally without transitioning to an admin role ... they can put stuff in their home directory but not globally. - I agree with Smooge in one of the messages he wrote ... there are many users who would like to run Fedora just like Windows95. That may be but that does not mean that Fedora should follow that idea. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote: On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski g...@czarc.net wrote: On Monday 30 November 2009 18:16:50 Adam Williamson wrote: Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges. Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do. There is already a security policy in place. It's not formalized nor is it written down but it's there. It's the current posture of Fedora. We set a root passphrase at the beginning of install and we give people the option of securing GRUB with a passphrase and encrypting the hard drive. We also have the unwritten rule of user privileges. It may be time to document our current posture to at least show where we are and the standard we expect all developers to live up to. In the process of documenting you may find that we are lacking somewhere. Yes, there has always been a security policy as defined by the written code (software). But, that is subject to individual interpretation. I agree that creating a written security policy is likely to identify shortcomings such as my point about the GRUB password. Lots of folks who use computers clearly do not understand the underlying technology and are clearly not paranoid enough. Given a home computer, do you really want your teenager installing file-sharing software. Recently, the US Congress discovered that some of their users had installed file-sharing software --- and the result was not positive. Fedora needs to provide good functionality while keeping our collective sanity ... we need software which is not just easy to use but is smarter about how it is used. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Monday 30 November 2009 22:40:07 Hal Murray wrote: g...@czarc.net said: ... A written description of the security policy is a must! ... Is the idea of a single one-size-fits-all security policy reasonable? I think Fedora has a broad range of users. No. Initially, I recommend one security policy and one reference implementation to test against. Each variation needs its own security policy and reference implementation definition. Later ones are easier to create because they can use the early ones as guidance. So, why go through all of this paperwork and bureaucratic bullshit? Well, those of us who have done this before believe that it is necessary. I do not like the bureaucratic BS any more than anyone else but, if you do not do it, then you are not quite sure what you have when you say that something meets security requirements. Gene -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Monday 30 November 2009 18:16:50 Adam Williamson wrote: On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote: Gene, (Ahh... someone with a similar background...) So the biggest question, to me, is to what standard do we start? There are plenty to choose from from DISA to NIST. I, personally, find the NSA's Guide to the Secure Configuration of Red Hat Enterprise Linux 5 very good and might be a good place to start. I'm not saying that we do everything that is in the guide but maybe take the guide and strike things out that don't make sense and add stuff to it that does make sense. Thanks for the thoughts, Gene and Eric. You seem to be running a long way ahead here :). I should probably say that I think I mistitled the thread: what I was really thinking about here is not 'security', but the more limited area of 'privilege escalation'. I'm not sure we're ready to bite off a comprehensive distro-wide security policy yet, to the extent you two are discussing. But, you did say the right words for what is needed to do security QA and not just privilege escalation. Where I'm currently at is that I'm going to talk to some Red Hat / Fedora security folks about the issues raised in all the discussions about this, including this thread, and then file a ticket to ask FESco to look at the matter, possibly including a proposed policy if the security folks help come up with one. And for the moment, only really concerned with the question of privileges. Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do. I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. Gene -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
Although I have read all of the messages on this thread as of the date/time of this message, I am replying to this first message with all of my comments. My background: I am currently retired but a few years ago I was still being paid the big bucks for working on computer security and security assessment of systems in US classified environments. On the whole, I believe that Adam has outlined a good approach to the problem of doing QA on security for Fedora! General comment: I have read messages which claim that the approach is wrong and that we need to look at things that a user can do rather than what a user cannot do. I disagree. While the right approach for design/development is to assume that a user can do nothing except what they are specifically authorized to do, for security QA this needs to be turned around and the testing needs to demonstrate what a user cannot do. On Monday 23 November 2009 17:08:31 Adam Williamson wrote: We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground. So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change. It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. +1 A written description of the security policy is a must! Without it being written down in simple english (with translations as appropriate), there will be far too much subjective interpretation of what the policy is. I believe spot's list is a good starting point for F13. However, the policy should consider how Fedora should work with respect to security and not how it does work as currently implemented. For example, you cannot currently login as root from the gui (gdm) interface but you can login as root from a virtual terminal ... is this the way the system should work? Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes. BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA. The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try. +1 You definitely need to define a reference implementation that will be tested. Security assurance testing is done on as-built systems ... not as designed! It may be possible but is not practical to test everything. [or will take so long that the release will no longer be supported] Furthermore, I believe you should initially focus on a small subset of what is in Fedora (perhaps gnome only) and with a selected set of services (servers). At this point in time, considering all of the various windows implementations (gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little of it in a forward direction. KISS!!! ... Given a written security policy for Fedora and a written description of the reference implementation that will be tested, these need to be vetted and tuned from comments. After a reasonable amount of time, these documents/specifications should be approved by the Fedora Executive Committee (or whatever). Any variation or change, should require additional approval. There should be some independent oversight of the security QA process to minimize subjective (re)interpretation. This will NOT make everyone happy. Sorry, but there is only so much resources and you really do not want this to be a black hole which consumes everything else. Start small, grow, and learn. Two years from now, the security policy, the reference installation/configurations, and the QA process for securtiy will likely be very different. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
On Wednesday 11 November 2009 06:41:58 Farkas Levente wrote: On 11/11/2009 11:53 AM, Richard W.M. Jones wrote: On Wed, Nov 11, 2009 at 10:14:21AM +, Richard W.M. Jones wrote: echo input | time cpio --quiet -o -H newc /path/to/fs/output Update: I found the -C option that lets me specify the blocksize, and raising it to something sensible (65536) shows major improvements in performance for all filesystems. echo input | time cpio -C 65536 --quiet -o -H newc /path/to/fs/output tmpfs 0.77 sx 1.0 ext2 1.12 sx 1.5 xfs1.66 sx 2.1 ext3 2.58 sx 3.4 ext4 5.59 sx 7.3 The new times are: tmpfs 0.20 sx 1.0 ext2 0.30 sx 1.5 xfs 0.41 sx 2.1 ext3 0.57 sx 2.9 ext4 0.44 sx 2.2 imho it's still a bug. wouldn't somehow rise the default or make the writes buffered or ... since the current situation is not correct. I am not sure if this is related or not ... During the F12 development cycle, I have done a number of installs on both bare hardware and qemu-kvm guests. In all cases, I have formatted the root (/) partition as ext4. I have noticed that formatting the partition for ext4 seems to take considerably more wall-clock time for ext4 partitions than my previous experience with ext3 partitions. I do not know if this is because ext4 formatting needs to do a lot more work than ext3 or if there is a performance issue. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bind-chroot directory permissions?
On Friday 25 September 2009 11:21:41 Tom Horsley wrote: I recently enabled dynamic DNS for the virtual machines I've been installing and named started getting errors (running as chroot) trying to write .jnl files to the /var/named directory under the chroot. Fixing the directory to be root:named 770 instead of root:named 750 took care of that. Then with the recent update of bind and bind-chroot, I started seeing these messages in the log: Sep 25 08:03:21 zooty named[12710]: dumping master file: tmp-PDw9vymVVL: open: permission denied I'm not sure what directory it is trying to write those in, but I found and chmodded a few more directories and haven't seen one of those messages since. Should directory permissions be adjusted in one or more of the rpms to take these things into account? 1. Don't turn selinux off on your local name-server system ... it actually works fine with bind/named. 2. You really do not need to run chroot'ed if you have selinux enabled. However, it will run fine and with selinux -- this will give you an belt and suspenders solution for named security. 3. As currently implemented on Fedora 11, dynamic updates (by dhcpd I assume) need to have your database files in either a dynamic or a slaves subdirectory of the named directory (either one will work). 4. Then, in the zone definitions in the named.conf file, you need to point to the subdirectory with something like: file dynamic/lcl.db; rather than: file lcl.db; Gene -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
dnssec-conf problem
Dnssec was introduced as a default in Fedora 11 and continues in Fedora 12.
The dnssec-conf package was introduced to modify/configure /etc/named.conf for
the dnssec support. Unfortunately, dnssec-conf (specifically /usr/sbin/dnssec-
configure has a significant problem. The problem is documented in bugzilla
reports:
https://bugzilla.redhat.com/show_bug.cgi?id=505754
https://bugzilla.redhat.com/show_bug.cgi?id=510290
https://bugzilla.redhat.com/show_bug.cgi?id=523973
I have closed 510290 and 523973 as dups of 505754.
Report 505754 has a comment by p...@xelerance.com dated 2009-06-25 that the
bug has been found and that the fix in is dnssec-conf 1.22 which will be posted
today (2008-06-25). Since that time ... nothing ... including and
especially no 1.22.
I am not sure what happened to Paul (accident? fired? three month vacation? ??)
but there appears to be no active author/creator/maintainer since late June or
since about three months ago.
I noticed that there is a current thread about package maintainers and
responsiveness ... I believe those comments apply here.
I understand that the forthcoming RHEL 6 will be based on Fedora 11 and, as
such, I expect that dnssec-conf will be included. Therefore, this possible
maintainer problem and the associated needed bugfix needs to be addressed.
Until the bugfix is implemented, I suggest that some user documentation be
added to advise users how to work around the problem. The work-arounds I have
found are:
1. Make such that options is immediately followed by a right brace ({)
and the same physical line or the options statement will not recognized .
2. Make sure that the options statement termination (};) is on its own
physical line.
3. For options sub-statements/items which themselves include a list, make
sure that the closing right brace }) is not on a separate physical line but
it after the last item in the list. Sub-statements/options-items which
themselves have a list as an operand can occur over multiple physical lines if
this is done.
4. Be sure that and dnssec-whatever sub-statements/options-items are on
separate physical lines or or named.conf will be butchered.
Another possible work around may be to remove the dnssec-conf package (I have
not tried this so I am not sure).
Gene
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how much junk should i have to install for a 32-bit toolchain?
On Monday 20 July 2009 08:30:51 Jonathan Underwood wrote: i may just throw 32-bit f11 on via virtualbox and do it all there. That works too. Or qemu-kvm which is available in the fedora repos. For some time (years), I have been using VMware guests to address the problem. I have now converted to using qemu-kvm under Fedora 11 to do the same thing. I create a guest of the desired target (Fedora9, Fedora 10, CentOS 5.3, etc.) and appropriate architecture (32 bit or 64 bit), and then build binary RPMs on those guests. This approach has worked well for me and, overall, minimizes the time I must spend to attempt to do something like creating good (they will work) 32 bit binaries on a 64 bit system. Gene -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
with atl1e driver: Corrupted MAC on input
I believe I have detected a significant problem with the atl1e driver for the Attansic Technology Corp. Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0) when running Fedora 11 preview with the latest updates. This controller is integrated on the ASUS M4A78 PRO motherboard. Although my problem occurred when I was running scp, I believe that the problem could also occur with other forms of data transfer and only show up as corrupted data (files). Thus, I thought this email appropriate to warn other users. My current solution is to install another NIC. This problem has been reported: https://bugzilla.redhat.com/show_bug.cgi?id=503288 http://bugzilla.kernel.org/show_bug.cgi?id=13404 This is no show stopper but may be of concern to other users. I am posting a separate copies of this email to the test and user mailing lists. Gene -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Running VMware-server on x86_64 Fedora 9
There are some problems running VMware-server on x86_64 Fedora 9. While VMware-server needs to run on a 64 bit (x86_64) host OS in order to run 64 bit guests, the application itself is a 32 bit (i386) application which does some magic to run 64 bit guests. With x86_64 Fedora 9, the install (and update) do not install i386 packages in addition to the x86_64 packages (at least as compared to Fedora 8). While googling did provide some information, there was no succinct description of what needed to be done to run VMware-server on x86_64 Fedora 9. Note: this applies to VMware-server 1.0.6 but may also be applicable to other versions. The real problem is that the VMware-server rpm provided by VMware does NOT include requires for the libraries it needs. 1. Install x86_64 Fedora 9 with development packages (e.g, compilers, etc.). 2. Install the following x86_64 packages: - kernel-devel - xinetd - perl-ExtUtils-Embed 3. Install the following i386 packages (e.g., yum install zlib.i386): - libXtst - libXt - libSM - libICE - zlib - libXrender - libXi - gtk-nodoka-engine 4. Then install the VMware-server rpm, run vmare-config.pl and vmware. This worked for me but your mileage may vary. Gene -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
