web/html/docs/release-notes/f12/en-US/html sect-Release_Notes-Security.html, 1.2, 1.3

Thu Nov 19 01:51:55 UTC 2009

Author: jjmcd

Update of /cvs/fedora/web/html/docs/release-notes/f12/en-US/html
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21579

Modified Files:
	sect-Release_Notes-Security.html 
Log Message:
Add warning about installing by non-priv user



Index: sect-Release_Notes-Security.html
===================================================================
RCS file: /cvs/fedora/web/html/docs/release-notes/f12/en-US/html/sect-Release_Notes-Security.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3

--- sect-Release_Notes-Security.html	10 Nov 2009 17:46:23 -0000	1.2
+++ sect-Release_Notes-Security.html	19 Nov 2009 01:51:55 -0000	1.3
@@ -2,7 +2,27 @@
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>5.2.Â Security</title><link rel="stylesheet" href="./Common_Content/css/default.css" type="text/css" /><meta name="generator" content="publican" /><meta name="package" content="Fedora-Release_Notes-12-en-US-0.1-1" /><link rel="home" href="index.html" title="Release Notes" /><link rel="up" href="sect-Release_Notes-Changes_in_Fedora_for_System_Administrators.html" title="5.Â Changes in Fedora for System Administrators" /><link rel="prev" href="sect-Release_Notes-Changes_in_Fedora_for_System_Administrators.html" title="5.Â Changes in Fedora for System Administrators" /><link rel="next" href="sect-Release_Notes-Virtualization.html" title="5.3.Â Virtualization" /></head><body class=""><p id="title"><a class="left" href="http://www.fedoraproject.org"><img src="Common_Content/images/image_left.png" alt="Product Site" /></a><a class="right" href="http://docs.f
 edoraproject.org"><img src="Common_Content/images/image_right.png" alt="Documentation Site" /></a></p><ul class="docnav"><li class="previous"><a accesskey="p" href="sect-Release_Notes-Changes_in_Fedora_for_System_Administrators.html"><strong>Prev</strong></a></li><li class="next"><a accesskey="n" href="sect-Release_Notes-Virtualization.html"><strong>Next</strong></a></li></ul><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h3 class="title" id="sect-Release_Notes-Security">5.2.Â Security</h3></div></div></div><div class="para">
 		This section highlights various security items from Fedora.
-	</div><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h4 class="title" id="sect-Release_Notes-Security-Lower_process_capabilities">5.2.1.Â Lower process capabilities</h4></div></div></div><div class="para">
+	</div><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h4 class="title" id="sect-Release_Notes-Security-Install-trusted-packages">5.2.1.Â Local users may install trusted packages</h4></div></div></div><div class="warning"><h2>Non-privileged users may install software.</h2><div class="para">
+				In Fedora 12, a <span class="emphasis"><em>local</em></span> user may install <span class="emphasis"><em>signed</em></span> packages without authentication. This is a change from Fedora 11.
+			</div></div><div class="para">
+			In common use cases, local desktop users frequently install packages. In Fedora 11, this required authentication. In Fedora 11, if the user wishes to install an unsigned package, a second authentication is required. Since the desktop user is typically the owner and sole user of the machine, the default was changed in Fedora 12 to allow a local user to install signed (trusted) packages without authentication. Unsigned packages continue to require authentication.
+		</div><div class="para">
+			This change only affects installs and updates made through the graphical interface. It does not affect <code class="command">yum</code>, nor does it allow packages to be removed without authentication.
+		</div><div class="para">
+			Some administrators may prefer the old behavior. To restore the Fedora 11 behavior, create a file in <code class="filename">/var/lib/polkit-1/localauthority/20-org.d</code> (name it anything you want) and the content should be 
+<pre class="screen">
+[NoUsersInstallAnythingWithoutPassword]
+Identity=unix-user:someone;unix-user:someone_else
+Action=org.freedesktop.packagekit.*
+ResultAny=auth_admin
+ResultInactive=auth_admin
+ResultActive=auth_admin
+</pre>
+		</div><div class="para">
+			It is important to note that, as of this writing, there is some discussion as to whether this feature may be reverted. There is also a question about whether the above fix works for all users. This document will be updated as new information becomes available.
+		</div><div class="para">
+			Those that want to follow the detailed discussion can refer to <a href="https://bugzilla.redhat.com/show_bug.cgi?id=534047">https://bugzilla.redhat.com/show_bug.cgi?id=534047</a>. Be advised that most of those commenting are developers and frequently have software and understanding beyond ordinary users.
+		</div></div><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h4 class="title" id="sect-Release_Notes-Security-Lower_process_capabilities">5.2.2.Â Lower process capabilities</h4></div></div></div><div class="para">
 			Daemons running as root have been reviewed and patched to run with lower process capabilities. This reduces the desirability of using these daemons for privilege escalation. Additionally, the shadow file permissions have been changed to <code class="literal">000</code> and several directories in <code class="filename">$PATH</code> have been set to <code class="literal">555</code> in order to prevent daemons without <code class="literal">DAC_OVERRIDE</code> from being able to access the shadow file or write to the <code class="filename">$PATH</code> directories.
 		</div><div class="para">
 			When someone attacks a system, they normally can not do much unless they can escalate privileges. This feature reduces the number of attack targets that can be used to escalate privileges. If root processes do not have all capabilities, they will be harder to use to subvert the system.
@@ -10,7 +30,7 @@
 			Processes with the root uid can still damage a system, because they can write to nearly any file and of course read the <code class="filename">/etc/shadow file</code>. However, if the system is hardened so that root requires the <code class="literal">DAC_OVERRIDE</code> capability, then only a limited number of processes can damage the system. This will not affect any admin abilities because they always get full privileges which includes <code class="literal">DAC_OVERRIDE</code>. Therefore, even if someone does successfully attack a root process, it is now harder for them to take advantage of this attack.
 		</div><div class="para">
 			A hardened system would have permissions like: <code class="literal">555</code> <code class="filename">/bin</code>, <code class="literal">555</code> <code class="filename">/lib</code>, <code class="literal">000</code> <code class="filename">/etc/shadow</code> and so on. The current scope is to cover the directories in <code class="filename">$PATH</code> variable, library dirs, <code class="filename">/boot</code>, and <code class="filename">/root</code>. This scheme does not affect SELinux in any way and complements it since capabilities are DAC controls and they have first vote on allowing an access.
-		</div></div><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h4 class="title" id="sect-Release_Notes-Security-SELinux_Sandbox">5.2.2.Â SELinux Sandbox</h4></div></div></div><div class="para">
+		</div></div><div class="section" lang="en-US" xml:lang="en-US"><div class="titlepage"><div><div><h4 class="title" id="sect-Release_Notes-Security-SELinux_Sandbox">5.2.3.Â SELinux Sandbox</h4></div></div></div><div class="para">
 			The SELinux sandbox allows a command to be run in a highly constrained fashion. Unfortunately, the nature of GUI applications is such that it is very difficult to use this capability on those applications that need it most.
 		</div><div class="para">
 			A new <code class="command">sandbox -X</code> command allows many GUI applications to be tightly constrained. By applying this within some web applications, a user may specify, for example, that Open Office should run normally when invoked by the user, but should be constrained when invoked from the web.


