-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/13/2011 10:29 AM, Tim wrote: > Tim: >>> Well, it /could/ stop either threat, however we don't run SELinux >>> as tightly as it could be run. > > Darr: >> I'm not sure who "we" is > > Us using it, and them who preset its parameters... > >> but I run it in restricted mode > > What's "restricted" mode? > > There's "enforcing" (SELinux doing what it does), "permissive" (SELinux > permitting everything and merely logging it), and "disabled" (self > explanatory) modes. > > With policies, we currently use "targeted," where some specific things > are targeted to be controlled by SELinux (known problems, or considered > to be a good idea), and other things are virtually left unmolested > (either because putting restrictions on everything, with a "strict" > policy, causes so many problems that the computer becomes unusable, or > good ways to do such restrictions haven't been worked out yet), or have > only generic restrictions placed upon them. > > You probably want to look up targeted versus strict policy, to get more > background on that. > > >> and rarely even get told something has mislabeled files... and when I >> do get such a message, an autorelabel and reboot nearly-always fixes >> it (I don't mind rebooting once a month or so... > > I can't remember getting any denials on anything that I was doing, other > than a brief play with Google Earth, some time ago (and that was their > fault). However, I do see various reports about things going on in the > background, that don't appear to be affecting what I'm doing. So they > tend to get ignored. > > For example, there's thousands of these: > > Summary: SELinux is preventing gnome-power-man (xdm_t) "execstack" > xdm_t. > > Detailed Description: SELinux denied access requested by > gnome-power-man. It is not expected that this access is required by > gnome-power-man and this access may signal an intrusion attempt. It is > also possible that the specific version or configuration of the > application is causing it to require additional access. > > And hundreds of these: > > Summary: SELinux prevented umount from mounting on the file or > directory "/proc/<pid>/mounts" (type "automount_t"). > > Detailed Description: SELinux prevented umount from mounting a > filesystem on the file or directory "/proc/<pid>/mounts" of type > "automount_t". By default SELinux limits the mounting of filesystems to > only some files or directories (those with types that have the > mountpoint attribute). The type "automount_t" does not have this > attribute. You can either relabel the file or directory or set the > boolean "allow_mount_anyfile" to true to allow mounting on any file or > directory. > We have lots of features to allow the unconfined_t domain get some confinement, but we choose to turn them off by default. Or better yet setup the default login account as staff_t. But this is difficult to do without getting the "SELinux sucks, turn SELinux off" responses. If you begin to further confine the desktop user by default, things will break and you need to further configure SELinux. I blogged about this a few years ago http://danwalsh.livejournal.com/25265.html?thread=181169 We can prevent lots of stuff, you could run your firefox session in sandbox or even multiple firefox sessions within multiple sandboxes, We can prevent executable/writable memory checks, we can confine mozilla_plugin and nsplugin but most of these have to be turned off because things can break. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZS9wACgkQrlYvE4MpobMuMACg2QVYXSM8RYVfWmGxILIPok6k SB4AoI+H+AiJMvh9ytPV8iKMxAZAmRAU =fgUv -----END PGP SIGNATURE----- -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
