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 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 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 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 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
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/listi
Re: abrt and bugzilla
On Saturday 21 November 2009 05:54:56 Caolán McNamara wrote: > On Sat, 2009-11-21 at 00:42 +, Colin Walters wrote: > > Look at it this way - it's more information than you had before, not > > less. And I personally have often been able to find a problem with no > > more than a traceback (especially given -debuginfo being installed, or > > an enthusiast/developer running code from revision control and thus > > having un-stripped binaries). > > Which brings up another thing, all the ones I'm getting are without > debuginfo installed, which is rather gruesome. Can we get info sharedlib > called in the gdb batch (https://fedorahosted.org/abrt/ticket/90) > I have had problems with using abrt to report a problem because the backtrace does not include symbolics ... that is, debuginfo was not downloaded and installed. At least once during the F12 development cycle I used abrt to report a problem and it downloaded and installed the needed debuginfo packages. Is abrt suppose to download and install debuginfo packages? Is this an option and if it is how is it enabled? Is there an abrt bug right now preventing debuginfo processing? Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Friday 20 November 2009 13:30:12 Simo Sorce wrote: > On Fri, 2009-11-20 at 12:23 -0600, Bruno Wolff III wrote: > > On Fri, Nov 20, 2009 at 08:48:56 -0500, > > > > Simo Sorce wrote: > > > On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote: > > > > On 11/20/2009 02:21 AM, Rudolf Kastl wrote: > > > > > there are also inconsistencies between gui clickery and shell > > > > > usage... simple example: > > > > > > > > > > click "shutdown" in gnome just does it in f12 > > > > > > > > > > > > Yeah, you can do that in F11 as well :( > > > > > > > > I agree, this needs protecting with a root password too. > > > > > > > > > Jeff this is silly. > > > Shutdown in console by default is perfectly fine, otherwise the user > > > can simply push the power button. > > > > > > I disagree. I don't want guests accidentally shutting down machines. If > > they have to hit the power button it makes it a bit harder to do by > > mistake. It isn't a huge deal, but I'd definitely prefer that the > > shutdown/restart GUI stuff not work unless your authenticated as root. > > I understand your point, but this is really splitting hairs. > In this case I think the default is fine because it is not a security > issue (if you have console access). If you still don't like it you > should change the default. +1 ... shutdown is not a security issue for a user with local console access and the same should apply to poweroff, halt, etc. On the other hand, installing new or updated packages can be a security issue and should require additional authentication such as root's password or (perhaps) being in the wheel group or some selinux attribute. > > Now, I know that changing PolicyKit related defaults is not easy at the > moment. But that's an issue of man hours, finding someone willing to > build a desktop tool that allows you to easily see current policies and > create local ones on the fly. > If the default is changed, then an easy-to-use gui tool is need to be available to adjust / change / (perhaps) define policies at the same time that that the policy change is made. One thing I consider really annoying are "are you sure" "popups" when some significant action (in the opinion of the developer) is done ... especially when the "popup" cannot be disabled. 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
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- 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
