FWN/Beats/Developments

SELinux Eats Babies, Confines Wives, Gives Birth

JonMasters plunged[1] his head into the lion's mouth with a request to "re-add" the option to disable SELinux (or change to permissive mode) during or shortly after installation of the OS. His reasons included the apparent random breaking of currently working applications due to policy changes and the lack of support via gnome-vfs for relabeling of files to fix context problems. He finished off by claiming that "unsuspecting Desktop users" should not have something as complex as SELinux forced on them without an easy way to disable it.

1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00059.html

Jon's examples of stuff that broke included attempting to use an ISO in virtmanager and running vpnc. He was at pains to point out that he had been running SELinux in "enforcing" for a long time and that he was reporting these problems because he thought that average "Desktop" users would be unable to use chcon to fix them.

Responses mostly emphasized that Jon was far from a typical user. SimoSorce argued[2] that, as a fellow developer, he had learned to expect labeling problems due to his non-standard usage and also how to fix them including changing policy for some of his commonly used packages. He noted that DanWalsh was very helpful in this regard. A brief discussion between SethVidal and MatthiasClasen suggested[2a] that nautilus has been fixed in rawhide to allow the labelling of files through gnome-vfs via the right-click "properties" dialog.

2. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00081.html

2a. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00088.html

DanWalsh wrote a detailed response[3] in which he commented that Jon had run vpnc from the command-line instead of from NetworkManager, this latter being standard usage. Dan thought that this contradicted Jon's claim that this problem would be typically faced by an ordinary desktop user without access to, or knowledge of, chcon. He further argued that the virt-manager problem was unlikely to be faced by such desktop users and went on to explain that "libvirtd is not unconfined whereas running qemu as a user is unconfined. Running qemu from libvirtd is still confined and is fixed by correct labeling. Hopefully the virt-manager people will assign an appropriate context at creation time, and/or default virtual machines to /var/lib/libvirt/images where they will be labeled correctly automatically."

3. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00127.html

Dan then commented that Desktop users are currently only confined with respect to executable memory checks in order to stop poorly written programs offering a means to execute buffer overflows. The use of PolicyKit, HAL and D-BUS to improve the user's desktop experience by running applications as root was mentioned by Dan as a further arena in which user confinement was necessary in order to prevent root exploits. He alluded to his recent presentations (e.g. [4],[5]) on confining users on Fedora 9 and rawhide as ways in which user types can be confined in customized ways to prevent such problems.

4. http://www.redhatmagazine.com/2008/07/02/writing-policy-for-confined-selinux-users/

5. http://danwalsh.livejournal.com/11913.html

DanielBerrange added[6] that the libvirt problem should be permanently fixed in Fedora 10 due to new storage management capabilities.

6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00128.html

Much of the rest of the discussion focused on the general problem of whether or not it was appropriate to offer uneducated users the option to disable intrinsic security. JesseKeating and AlanCox[7] thought that a lack of knowledge precluded a meaningful choice and JamesMorris agreed[8], and referenced BruceSchneier on risk evaluation and security. He concluded that "Punting the decision to the end user during installation is possibly the worst option. It's our responsibility as the developers of the OS to both get security right and make it usable. It's difficult, indeed, but not impossible."

7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00073.html

8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00091.html

ColinWalters added[9] his voice to the chorus of those that believed that it was inappropriate to offer such options during installation. He suggested that system-config-selinux post-installation was available for those that really needed it and that the paths to solve this problem were not restricted to a binary "enabled or disabled by default" but included other possibilities such as: rawhide defaults to permissive; automatic reporting of denials to the Fedora developers; shifting more objects into unconfined_t in the default while confining network-facing services; and finally, using a regression test suite to ensure updates are not problems. Jon was largely in agreement[10] and again wanted to emphasize that he was appreciative of both Dan's rapid fixing of problems and the usefulness of SELinux itself, but he thought that the "tuning down of default policy" was the best option to enable "Desktops where people can just get stuff done." AlanCox did not buy this[11] and argued that no progress would be made without exposing us all to the problems which would then get fixed. He likened the discussion to the years-old one which had taken place concerning firewalls being enabled by default: "Sorry if I sound fed up of all of this but I spent 9 months fighting people years back to get firewalling enabled by default, and that had all the same arguments. Today nobody (even Microsoft) would propose otherwise." Alan added that setroubleshoot should be a bit more user friendly.

9. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00072.html

10. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00075.html

11. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00099.html

Apparent agreement on this last point exposed a further problem with several posters suggesting[12],[13] that a Windows Vista-like prompt to run a program which had been flagged as dangerous would be useful. SimoSorce and AndrewFarris highlighted[14],[15] the potential flaw of such an approach. SurenKarapetyan argued[16] that he and others were capable of making an informed choice to disable SELinux and that Fedora was becoming increasingly restricted in such freedoms. SimoSorce retorted[17] that re-adding the "disable SELinux" option during installation was wrong from a usability perspective and that if was both selfish and incompetent for Fedora developers to simply disable SELinux instead of dogfooding it. Suryen referenced Smolt statistics to bolster his case and argued that it was wrong to decide "for the user" what to do. AlanCox responded[18] that such statistics were meaningless because it was impossible to know how many of the users disabling SELinux had made an informed, correct choice.

12. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00101.html

13. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00117.html

14. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00124.html

15. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00125.html

16. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00184.html

17. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00187.html

18. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00221.html

Several other posters expressed frustration with the repetition of such objections to SELinux and there the thread would have lain, flogged senseless except that StewartAdam volunteered[19] to help write an "setroubleshoot" plugin that "allowed users to report audit denials similar to how kerneloops does. setroubleshoot then bridges the gap between new users and fixing the policy, and it could be done with stats to see what areas need work on. Naturally it would only report the denials the user requests to be submitted, so no "calling home" stuff." This proposal seemed to draw general approval[20],[21].

19. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00131.html

20. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00142.html

21. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00137.html

Help Wanted: Samba4, Heimdahl, OpenChange

An exciting promise of increased interoperability with Microsoft Exchange was wafted[1] in front of us when AndrewBartlett requested help in packaging OpenChange[2] and its dependencies. This would result in "evolution" and "kdepim" being able to use the native MAPI protocol and free them from relying upon fragile WebDAV access to the server.

1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00002.html

2. https://fedoraproject.org/wiki/Features/OpenChange

JesseBarnes was excited enough to start helping out and after some pointers from RahulSundaram[3] and Andrew on how to get started[4] he very quickly got going[5]. AlexanderBoström and MarceloGobelli also expressed willingness to help.

3. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00029.html

4. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00027.html

5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00090.html

Java, So Many Free Choices

PeterLemenkov requested[1] that the current wiki[2] be updated to summarize the status of the four available implementations[3] of Java: GCJ, OpenJDK/IcedTea, ecj, java-1.6.0-sun (this latter for EPEL only). His interest had been sparked by the observation that some packages were built with GCJ and had not been rebuilt with OpenJDK which he presumed to be superseding GCJ/ecj.

1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00151.html

2. http://fedoraproject.org/wiki/Java

3. Strictly speaking although these all share some features it's a bit misleading to lump them together. OpenJDK is Sun Microsystems' open-sourced implementation of the Java Platform (SE). This includes classes, an interpreter, compiler etc., whereas ecj was solely a bytecode compiler from the Eclipse project. GCJ can compile Java to bytecode or to native machine code and provides a linkable runtime which can interpret bytecode. IcedTea was a project which replaced non-Free parts of OpenJDK with GNU implementations.

AndrewHaley promised[4] to update the wiki and commented that due to limited people resources it was difficult to say exactly what the future of GCJ/ecj would be and that OpenJDK support needed to be extended across more platforms. He explained[5] that there was no need to use OpenJDK to rebuild packages which already compiled with GCJ and expanded on his earlier comment with the information that most non-x86 platforms were currently not fully supported by OpenJDK.

4. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00152.html

5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00169.html

When MattBooth suggested that GCJ would be needed until OpenJDK could support AOT compilation AndrewOverholt responded[6] that JIT compilation (as implemented by OpenJDK's Hotspot virtual machine) removed this need. AndrewHaley disagreed [7] for at least the case of lower-powered boxes which would benefit from AOT.

6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00185.html

7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00186.html

After all this talk about the many Free choices available in Java KevinKoffler wondered[8] whether some of the other virtual machines, such as ChristianThalinger's cacao[9] or GaryBenson's shark[10], both of which attempt to re-implement Hotspot in more portable ways, would be receiving attention. AndrewHaley responded[11] that help was welcome, "building Cacao + OpenJDK on one of the secondary arches and reporting back on how well it works would be massively useful."

8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00154.html

9. http://www.cacaovm.org/

10. http://gbenson.net/?p=67

11. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00168.html

Fedora 9 Now Officially Supported On Itanium/IA64

An announcement[1] by PraritBhargava of the availability of Fedora 9 on the ia64 "itanium" platform is the first fruit of the work done (see FWN#90[2], FWN#92[ 3]) to open up the Fedora project to "secondary architectures."

1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00110.html

2. http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal

3. http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont.

This means that it is now possible to run Fedora on an expanded range of high end hardware (from HP, SGI, NEC, Fujitsu, Unisys, Hitachi and Bull according to the architecture maintainers[4]. The release notes inaccurately describe this as a "beta" but DougChapman clarified that it is a GA release.

4. http://fedoraproject.org/wiki/Architectures/IA64

Prarit warned that there were a few important points of which to be aware including some slight source differences from stock Fedora 9. Consequently attempts to use yumdownloader will pull in SRPMS which do not match the actual source used to produce the ia64 binaries. MichaelSchwendt wanted to know why the ia64 release was out of sync with the other architectures and exactly what patches had been applied to stock Fedora. DougChapman answered[5] that future releases would hopefully reflect the experience gained in this very first "secondary architecture" and result in near perfect synchronization. He added that the changes to stock Fedora 9 source were in Fedora CVS so there were "no special ia64 patches floating around" and that the ia64 Everything repository had about 98% of the packages available on other arches. The builds are conducted on a separate Koji server using an identical method to the other architectures.

5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00118.html

DavidWoodhouse asked[6] why the download URL was so different to that of other supported architectures. BillNottingham responded[7] that ia64 was intentionally left off the Fedora master mirror due to space constraints.

6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00138.html

7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00143.html

RichardJones wanted[8] to know how to build Rawhide packages against ia64 using Koji and PaulHowarth provided[9] some sample Koji commands. DanHorak thought that fedora-packager-setup should provide some default configs in ~/.koji.

8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00160.html

9. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00165.html

Running As Root

A tired JerryWilliams asked[1] that the prompt which warns users that they have logged in as root to a session should have a means to easily disable it: "People login as root and have to keep clicking "Continue" and it slows things down."

1. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01500.html

TomCallaway disagreed[2], likening this to "using a loaded shotgun as a golf club, and what you're suggesting is that we take the safety off, because it interferes with your golf game." He suggested that the preferred behavior was to login as a normal user and then use sudo or su to elevate privileges to those of root only when necessary. Jerry decided[3] to re-think why he needed such root privileges and consequently drew attention to the lack of a non-root account setup on install, the presence of applications such as browsers in the root GUI profile, and the need to know the root password to use some configuration tools anyway.

2. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01501.html

3. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01521.html

Some of these points have received prior developer attention (see FWN#103 "Root Login And Display Managers In Rawhide"[4]) and were specifically discussed with reference to the Desktop Live spin.Tom acknowledged[5] that Jerry's questions were valid and wondered what had happened to "making the root GUI session a super-minimal session." DougLedford also mounted[6] a spirited defense of the occasional need to log in as root, although he conceded that it should not be made too easy to do so. His reasons included scenarios in which network-provided accounts and authentication are unavailable.

4. http://fedoraproject.org/wiki/FWN/Issue103#Root.Login.And.Display.Managers.In.Rawhide

5. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01522.html

6. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01538.html