Request to re-add option to disable SELinux

[Jon Masters]

Hi folks,

I'd like to see the re-introduction of an option during (or shortly
after, i.e. during firstboot) installation to disable SELinux, or set it
to be permissive. My reason for making this request includes:

*). A number of activities are not possible today, with SE Linux enabled
and enforcing on a default F9 installation. I can give examples -
downloading an ISO image and expecting to use it in virt-manager,
creating a virtual machine in a non-standard location, etc.

*). Policy changes will randomly stop things from working that used to
work. Especially on the Desktop, where many possible code paths (SE
Linux works by denying until an exception is found and added to the
policy...requiring all code paths to be exercised) exist to do
something. I found this last week when VPNC randomly broke.

*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

Cheers,

Jon.

[Jesse Keating]

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?
--
Jesse Keating
Fedora -- Freedom? is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080702/a807dea5/attachment.bin

[Jon Masters]

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

I see your logic Jesse, and I did think about it. But one might also
say, "how about we just force it down their throats because it's good
medicine for them?" ;) I'm concerned that this is what's happening :)

I think what's needed is a nice little paragraph summarizing what
SELinux is aiming to do, and then the old option of setting permissive
or disabling - users can then set permissive if they prefer to.

Jon.

[Jon Masters]

Post by Jon Masters
I think what's needed is a nice little paragraph summarizing what
SELinux is aiming to do, and then the old option of setting permissive
or disabling - users can then set permissive if they prefer to.

Note that when I say this, I'm one of the users who might well turn it
off (well, set permissive) again on future installs. I've lived with
SELinux enforcing on F9 for under two weeks and have found it highly
inhibitive to performing many regular everyday tasks I'm used to.

I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".

Dan, et al, no offense, but we need the option to come back :)

Jon.

[0] It had been almost ten years since I last read through all that
documentation. So although I learned a lot about our current policy, and
what has changed over the years in SELinux, so that I could understand
the current targeted policy source, this isn't something regular Fedora
users should have to do in order to be using their computers :)

[Alan Cox]

Post by Jon Masters
I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".

The desktop is where it is most needed.

But here is a silly question - why are you using vpnc if you turn SELinux off,
telnet would be faster too ?

Alan

[Jon Masters]

Post by Alan Cox

Post by Jon Masters
I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".

The desktop is where it is most needed.

Yes, in a perfect world in which policy and reality were so well aligned
that everything just worked, all of the time.

Post by Alan Cox
But here is a silly question - why are you using vpnc if you turn SELinux off,
telnet would be faster too ?

I didn't turn SELinux off. I'm forcing myself to use it in enforcing
mode, and I will continue to do so. But I think it's absolutely nuts to
expect the average Fedora desktop user to do so :)

Jon.

[Simo Sorce]

Post by Jon Masters

Post by Alan Cox

Post by Jon Masters
I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".

The desktop is where it is most needed.

Yes, in a perfect world in which policy and reality were so well aligned
that everything just worked, all of the time.

Post by Alan Cox
But here is a silly question - why are you using vpnc if you turn SELinux off,
telnet would be faster too ?

I didn't turn SELinux off. I'm forcing myself to use it in enforcing
mode, and I will continue to do so. But I think it's absolutely nuts to
expect the average Fedora desktop user to do so :)

1) you are not the average user, your experience is biased and your
usage patterns are not standard

2) I use SELinux in enforcing mode since F8, I had almost no problems, I
do development and all. I know what SELinux is and when to change to
permissive.

Moreover, given I am doing development and I am fiddling with
non-standard stuff I expect to have randomly problems with SELinux
(which is all about blocking non-standard behavior), so I just took my 2
hours self-teaching course on SELinux and know how to diagnose and
change labels when needed. I even ventured into changing some policy for
the packages I work on, although Dan Walsh is super in helping out with
that stuff and learning how to write policies is not strictly needed.

Take your time, learn what SELinux is and help back to make it better my
providing changes relative to packages you own or you use most. This
will be abetter use of your time.

I wonder if windows developers had the same attitude toward NTFS ACLs
when Microsoft started transitioning them from FAT ... I think us Linux
devs can handle SELinux, conceptually and practically.

Simo.

[Jon Masters]

Post by Simo Sorce
1) you are not the average user, your experience is biased and your
usage patterns are not standard

I agree I'm not a "typical user", however some of the things I've had
problems with are being used by typical users - I'm deliberately trying
to avoid examples of copying configuration files and the like :)

Post by Simo Sorce
Take your time, learn what SELinux is and help back to make it better my
providing changes relative to packages you own or you use most. This
will be abetter use of your time.

I'm all for helping to find and fix policy issues - why do you think I
left it enabled :) I've followed SELinux on and off for about a decade,
though this is the first time I've tried enforcing on a "desktop" box.
And I feel that my previous reasoning for turning it off on my desktops
and laptops is once again justified...unfortunately.

Post by Simo Sorce
I wonder if windows developers had the same attitude toward NTFS ACLs
when Microsoft started transitioning them from FAT ... I think us Linux
devs can handle SELinux, conceptually and practically.

That's a lousy example. I use Linux ACLs and have done since long before
they were upstream and in stock vendor kernels - ACLs are great, and
we're not shipping a complex default set of ACLs anyway :)

Let's compare apples and apples :)

Jon.

[Daniel J Walsh]

Post by Jon Masters

Post by Jon Masters
I think what's needed is a nice little paragraph summarizing what
SELinux is aiming to do, and then the old option of setting permissive
or disabling - users can then set permissive if they prefer to.

Note that when I say this, I'm one of the users who might well turn it
off (well, set permissive) again on future installs. I've lived with
SELinux enforcing on F9 for under two weeks and have found it highly
inhibitive to performing many regular everyday tasks I'm used to.
I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".
Dan, et al, no offense, but we need the option to come back :)
Jon.
[0] It had been almost ten years since I last read through all that
documentation. So although I learned a lot about our current policy, and
what has changed over the years in SELinux, so that I could understand
the current targeted policy source, this isn't something regular Fedora
users should have to do in order to be using their computers :)

But you were running a vpnc from the command line not the one launched
by network manager which was not broken. I don't know of many desktop
users who would do this.

So saying it should not be enabled for someone on the desktop because
they would be unable to chcon is contradicted by your statement.

The other problem you talked about is virtmanager also not that likely
to be run by your standard desktop user. We are working with the virt
team to make this simpler. libvirtd is not unconfined and 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.


The only confinement we have on real "Desktop users" by default. IE
Users that do not know the root password, is the executable memory
checks. These have been a pain in the past but they are getting better.
They usually are caused by badly written programs or bad labels on
programs that require java, wine, mono. But these checks can
successfully stop buffer overflow attacks. So they are important.

Other places where user confinement hits is through the use of
PolicyKit/Hal/dbus applications where code gets run as root on the users
behalf. PolicyKit/Hal/Dbus are great steps forward in usability for
users but should be treated as potential threats to the security of the
system. As a bug in anyone of these new apps could lead to a root
exploit. So SELinux needs to be used to confine the new desktop apps.

In Rawhide and Fedora 9 you can now actually confine the user using some
of the stuff I have been talking about in my blogs and presentations so
if you have a managed desktop user, someone who does not know the root
password, you can use these to really lock down the user on a system.
guest, xguest, user and staff are all available in Fedora 9 as well as
the unconfined user.

[Daniel P. Berrange]

Post by Daniel J Walsh
The other problem you talked about is virtmanager also not that likely
to be run by your standard desktop user. We are working with the virt
team to make this simpler. libvirtd is not unconfined and 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.

An update to F9 post GA set the default location to this directory.

For F10 we hope to fix the problem permanently by making use of libvirt's
new storage management capabilities for manipulating disks / files which
will ensure the correct context is always set.

Daniel

[Colin Walters]

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Yeah, we're trying to make installing Fedora not be a Choose Your Own Linux
Adventure game.

Either the SELinux policy works well enough that it is enabled by default
and supported, or it's not.

Besides, the option already exists - you can system-config-selinux after
installing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080702/4af05271/attachment.html

[Jon Masters]

Post by Colin Walters
Yeah, we're trying to make installing Fedora not be a Choose Your Own
Linux Adventure game.

I agree (partially) with that sentiment. Though it can obviously go way
too far with the aim of making life "easier" during a 10 minute install.

Post by Colin Walters
Either the SELinux policy works well enough that it is enabled by
default and supported, or it's not.

If it were really black and white like that, then I'd have to argue for
SELinux to be disabled by default on new Fedora installs and have users
go into the system config dialog to turn it back on. After all, if

Post by Colin Walters
Besides, the option already exists - you can system-config-selinux
after installing.

Then consider, those who know what SELinux is are more likely to know
about that dialog, and therefore more likely to turn it on. If you don't
like that, then I suggest giving thought to re-instating the option :)

Jon.

[Colin Walters]

Post by Jon Masters

Post by Colin Walters
Yeah, we're trying to make installing Fedora not be a Choose Your Own
Linux Adventure game.

I agree (partially) with that sentiment. Though it can obviously go way
too far with the aim of making life "easier" during a 10 minute install.

I don't think we can go too far in cutting out the crap from the install
process for desktops. The target audience is (or should be) people who have
*more important things* to do with their time than play Build My Own Linux.
They hit "Next" on the partitioning screens, firewall, etc.

If our defaults are broken, we should acknowledge that as a bug instead of
foisting the choice onto our users.

Post by Jon Masters
Either the SELinux policy works well enough that it is enabled by

Post by Colin Walters
default and supported, or it's not.

If it were really black and white like that, then I'd have to argue for
SELinux to be disabled by default on new Fedora installs and have users
go into the system config dialog to turn it back on. After all, if

Yes, I think what you should be arguing is that it should be permissive or
disabled by default.

I'm not sure I would agree with that argument personally given that I see
little hope for any other extended security system (e.g. AppArmor is
architecturally broken).

There are plenty of other possible choices besides just enabling by default
or disabling:

o Default rawhide installs to permissive
o Create a system that automatically sends denials back to Fedora and treat
them like crashes
o Tune down the default policy to move more things back into unconfined_t,
and focus more strongly on vulnerable network servers like Samba, Apache
etc.
o Actually have a regression test suite for Fedora and run updates through
it

etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080702/afea1d02/attachment.html

[Jon Masters]

Post by Colin Walters
I don't think we can go too far in cutting out the crap from the
install process for desktops.

Like I said, I like the sentiment ;)

Post by Colin Walters
If our defaults are broken, we should acknowledge that as a bug
instead of foisting the choice onto our users.

Ok, so...

Post by Colin Walters
Yes, I think what you should be arguing is that it should be
permissive or disabled by default.

Ok then let me just say it. I think the default should be permissive or
disabled by default. I was hoping to not have to say that - but I think
it's a lot safer on the mass userbase of Fedora than thrusting a fully
enforcing SELinux policy set upon them. If I'm having to hack on the
policy files on my laptop, there's no hope for a desktop user.

Post by Colin Walters
I'm not sure I would agree with that argument personally given that I
see little hope for any other extended security system (e.g. AppArmor
is architecturally broken).

Oh, see this is why I didn't want to just say "let's turn it off by
default", because people read it as an attack on SELinux itself. But it
doesn't have to be like that. SELinux is well designed (App Armor is
basically crackrock in my personal opinion) but it's extremely
complicated in terms of the policy that exists. It's also not for
everyone, in my opinion. I think that SELinux makes great sense on a
server running a timesharing environment, far less on a desktop.

Post by Colin Walters
There are plenty of other possible choices besides just enabling by
o Default rawhide installs to permissive

And yet the issues I've had have all been on F9, stock.

Post by Colin Walters
o Create a system that automatically sends denials back to Fedora and
treat them like crashes

There's still a lead time of days, or weeks. Dan is *very* good (I'm
being careful here to explicitly say I'm not attacking the folks behind
the policy - he updated the policy within a day of e.g. the VPNC issue)
but the whole thing is still very reactionary to problem reports. If a
user tries to do some of the things I tried, and they fail, they'll just
give up on trying, and think that it's all a waste of time.

Post by Colin Walters
o Tune down the default policy to move more things back into
unconfined_t, and focus more strongly on vulnerable network servers
like Samba, Apache etc.

This absolutely the most essential thing to be doing. I've been arguing
this for ever and ever. Personally, I think SELinux is a great tool on
servers to protect network facing stuff...but there needs to be a middle
ground on Desktops where people can just get stuff done. I haven't
pushed this on fedora-devel - I didn't expect a warm response ;)

Post by Colin Walters
o Actually have a regression test suite for Fedora and run updates
through it

Well, while we're at it, we really need to encourage more people to use
bodhi and start voting (and thereby assigning karma), and knowing about
updates (which should only ever contain essential fixes). But that's
another whole bucket of worms for a different thread.

Jon.

["Sankarshan (সঙ্কর্ষণ)"]

Post by Jon Masters
Ok then let me just say it. I think the default should be permissive or
disabled by default. I was hoping to not have to say that - but I think
it's a lot safer on the mass userbase of Fedora than thrusting a fully
enforcing SELinux policy set upon them. If I'm having to hack on the
policy files on my laptop, there's no hope for a desktop user.

One can argue that the path to an objective where everything just works
with SELinux 'on' begins by forcing the bitter syrup down the throats.

To extend your reasoning, if it were disabled by default, how would one
move towards just works ?

[Casey Dahlin]

Post by "Sankarshan (সঙ্কর্ষণ)"

Post by Jon Masters
Ok then let me just say it. I think the default should be permissive or
disabled by default. I was hoping to not have to say that - but I think
it's a lot safer on the mass userbase of Fedora than thrusting a fully
enforcing SELinux policy set upon them. If I'm having to hack on the
policy files on my laptop, there's no hope for a desktop user.

One can argue that the path to an objective where everything just
works with SELinux 'on' begins by forcing the bitter syrup down the
throats.
To extend your reasoning, if it were disabled by default, how would
one move towards just works ?

Agreed.

To put it more directly, why am I reading about your issues on
fedora-devel and not in bugzilla?

--CJD

[Alan Cox]

Post by Jon Masters
If it were really black and white like that, then I'd have to argue for
SELinux to be disabled by default on new Fedora installs and have users
go into the system config dialog to turn it back on. After all, if

"This car has brakes, enable them ?"
"Would you like the seatbelts to work ?"
"Shall I enable the airbag ?"

Post by Jon Masters
Then consider, those who know what SELinux is are more likely to know
about that dialog, and therefore more likely to turn it on. If you don't
like that, then I suggest giving thought to re-instating the option :)

One of the Gnome talks summed this up nicely long ago - how do most users
see dialogue boxes like that - the answer is as random noise you hit the yes
button too.

SELinux should be disablable is the wrong discussion. The discussion you should
be having is "I've filed a few bugs where SELinux didn't magically do the right
thing, how do we fix them and can we make these less likely to occur in future"

If it was a car this discussion ie - "I had a brake problem so I disabled them"
would not be considered sane

Alan

[Jon Masters]

Post by Alan Cox

Post by Jon Masters
If it were really black and white like that, then I'd have to argue for
SELinux to be disabled by default on new Fedora installs and have users
go into the system config dialog to turn it back on. After all, if

"This car has brakes, enable them ?"

Well, you can turn the ABS on and off in some cases.

Post by Alan Cox
"Would you like the seatbelts to work ?"
"Shall I enable the airbag ?"

You can turn the child restraint passenger system on/off on most models
of car to deal with the injury sustained from airbag deployment.

"Would you like to use regular gas or premium?"

Post by Alan Cox
SELinux should be disablable is the wrong discussion. The discussion you should
be having is "I've filed a few bugs where SELinux didn't magically do the right
thing, how do we fix them and can we make these less likely to occur in future"

I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

Post by Alan Cox
If it was a car this discussion ie - "I had a brake problem so I disabled them"
would not be considered sane

No, but there are many other more suitable analogies :)

Jon.

[Andrew Farris]

Post by Jon Masters

Post by Alan Cox
SELinux should be disablable is the wrong discussion. The discussion you should
be having is "I've filed a few bugs where SELinux didn't magically do the right
thing, how do we fix them and can we make these less likely to occur in future"

I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

selinux-policy-targeted is precisely that.

[Jon Masters]

Post by Andrew Farris

Post by Jon Masters

Post by Alan Cox
SELinux should be disablable is the wrong discussion. The discussion you should
be having is "I've filed a few bugs where SELinux didn't magically do the right
thing, how do we fix them and can we make these less likely to occur in future"

I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

selinux-policy-targeted is precisely that.

Or more precisely, it would like to be that. Abrupt, single line replies
like the above amuse me perhaps more than they should, because they
carry the implication that I didn't actually consider what is currently
implemented in Fedora before sending my original mail ;)

Anyway. I've tried to make my point, I'm done now :)

Jon.

[Andrew Farris]

Post by Jon Masters

Post by Andrew Farris

Post by Jon Masters

Post by Alan Cox
SELinux should be disablable is the wrong discussion. The discussion you should
be having is "I've filed a few bugs where SELinux didn't magically do the right
thing, how do we fix them and can we make these less likely to occur in future"

I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

selinux-policy-targeted is precisely that.

Or more precisely, it would like to be that. Abrupt, single line replies
like the above amuse me perhaps more than they should, because they
carry the implication that I didn't actually consider what is currently
implemented in Fedora before sending my original mail ;)
Anyway. I've tried to make my point, I'm done now :)

I apologize for the brevity then, but having read your previous mails it seemed
quite clear you hadn't looked at what targeted policy is when asking for it. If
there are specific situations, or policy bugs, or services you feel shouldn't be
confined under targeted policy it might make sense... but asking for a limited
set of services when it exists is just about as confounded as you can get. I
meant (and still mean) no offense, but if you want more thoughtful comments it
would help to be more clear about what you have and haven't already learned
about the situation.

[Alan Cox]

Post by Jon Masters
I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

How will you know you have "fixed" it if you have the bits in question
turned off - you won't. You have no meaningful way to make progress.

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.

This is the same thing ..

As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)

[Ahmed Kamal]

Why don't we have a compromise policy, where interactive users are not
restricted except their browsers? System daemons would be restricted of
course.
Another suggestion, is when something breaks because of selinux, and I get a
balloon about it. However, I am unable to modify selinux policy to
"correctly" fix that problem. The suggestion is to allow the user a
mechanism to launch the affected program in selinux-free mode ( like launch
as administrator from the Vista world!). Basically, selinux builds very
tight walls around the system, the end user, needs a hammer to break some of
these walls to get his work done. If we don't provide the hammer, he'll end
up turnning it off completely!

Post by Alan Cox

Post by Jon Masters
I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

How will you know you have "fixed" it if you have the bits in question
turned off - you won't. You have no meaningful way to make progress.
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.
This is the same thing ..
As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080703/9c18ed75/attachment.html

[Bruno Wolff III]

On Thu, Jul 03, 2008 at 11:50:59 +0300,

Post by Ahmed Kamal
Another suggestion, is when something breaks because of selinux, and I get a
balloon about it. However, I am unable to modify selinux policy to
"correctly" fix that problem. The suggestion is to allow the user a

audit2allow can be used to let the program run. As far as "correctly" fixing
things, that isn't going to be automated. In a lot of cases its the program
that is broken, not the policy. Someone needs to look at what is happening
and figure out what the real problem is.

[James Morris]

Post by Alan Cox
As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)

The good thing about setroubleshoot is that it has a plugin architecture,
so people can write better/more plugins. What's lacking are obvious
documents explaining how to do it, alas.


- James

[Mike Chambers]

Post by Alan Cox
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.
This is the same thing ..
As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)

I agree with Alan here, that if selinux is indeed a great program to
help secure the OS and anything else, it at least needs to be a LOT more
user friendly.

Ok, don't give me this MS to linux compare bit on what I am comparing
next, it's the comparing of wording and concept it's done in, not
details and stuff LOL. Anyway, Vista came out with that (I forget the
damn program name) program that when certain programs/files run, you get
a dialog box that you have to continue (to allow it to run) or cancel.
Now, no this isn't exactly the same, but it is in a way. They both
provide a little better security than with out it. BUT, in Vista, the
user doesn't have to relabel something, or go to the CLI, or whatever.
They get a little question stating this program wants to run, do you
give it permission. That's it, nothing else (might not like that dialog
all the time though, I am sure). And that is what I am trying to say
for selinux, that it needs to allow things to do what they need, and if
not, a simple little question or whatever to allow it. The user should
NOT have to go to the CLI for anything. They shouldn't have to do this
command or that command, JUST HIT YES OR NO!!

Well anyway, not ranting or raving. Just trying to maybe help clarify
what Jon was talking about, and what Alan was saying. SELinux I am sure
is a wonderful thing, and just needs to be I guess, dumbed down or
whatever so the user clearly understands what it is doing or not doing
and to present the user with simple to do questions/answers/buttons or
whatever to push/answer.

[Simo Sorce]

Post by Mike Chambers
And that is what I am trying to say
for selinux, that it needs to allow things to do what they need, and if
not, a simple little question or whatever to allow it. The user should
NOT have to go to the CLI for anything. They shouldn't have to do this
command or that command, JUST HIT YES OR NO!!

This nice program you just download from the interweb is trying to
access your keyring file directly to access your passwords: do you want
to allow it? YES / NO

I bet 90% of the people would hit yes.

This is the reason why the Vista approach is just a pain and a failure
at the same time and should never been taken as an example.

Simo.

[Andrew Farris]

Post by Mike Chambers

Post by Alan Cox
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.
This is the same thing ..
As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)

I agree with Alan here, that if selinux is indeed a great program to
help secure the OS and anything else, it at least needs to be a LOT more
user friendly.
Ok, don't give me this MS to linux compare bit on what I am comparing
next, it's the comparing of wording and concept it's done in, not
details and stuff LOL. Anyway, Vista came out with that (I forget the
damn program name) program that when certain programs/files run, you get
a dialog box that you have to continue (to allow it to run) or cancel.
Now, no this isn't exactly the same, but it is in a way. They both
provide a little better security than with out it. BUT, in Vista, the
user doesn't have to relabel something, or go to the CLI, or whatever.
They get a little question stating this program wants to run, do you
give it permission. That's it, nothing else (might not like that dialog
all the time though, I am sure). And that is what I am trying to say
for selinux, that it needs to allow things to do what they need, and if
not, a simple little question or whatever to allow it. The user should
NOT have to go to the CLI for anything. They shouldn't have to do this
command or that command, JUST HIT YES OR NO!!

Working to add a simple 'press yes or no' is an exercise in futility... general
users unquestioningly press yes and go on with their business whether they
should have or not. There is no effective difference from turning SELinux off.
If/When a program misbehaves and represents a security risk the user will have
no means to know whether it should or should not be allowed... and training to
say yes just because its an action they 'initiated by clicking' is horrible.

I would agree that some GUI tools would be a great fix, but not in the way Vista
has chosen to do them, because that is a fake and pointless security comfort
blanket and nothing more. For these actions the user should at minimum have to
type an administrator password (for instance any user/pass combo that has
adequate PolicyKit authorization to make selinux policy changes).

Post by Mike Chambers
Well anyway, not ranting or raving. Just trying to maybe help clarify
what Jon was talking about, and what Alan was saying. SELinux I am sure
is a wonderful thing, and just needs to be I guess, dumbed down or
whatever so the user clearly understands what it is doing or not doing
and to present the user with simple to do questions/answers/buttons or
whatever to push/answer.

The problem is that the general user does NOT understand even with the
explanation given. I've been struggling to understand selinux myself for
several years and it is far from clear what is happening and why all the time.
What is more difficult is knowing whether that application should have been
allowed to do what it tried to do, and I'm far from a general desktop user.

SETroubleshoot is a great step forward for helping users know why selinux
denials occur, but a simple dialog box will NEVER be adequate for a general user
to know whether the application is doing something inappropriate, and whether
they should force it to be allowed or not.

[Matej Cepl]

Post by Mike Chambers
They get a little question stating this program wants to run,
do you give it permission.

And yes, that's the reason why Vista is still totally broken
security-wise. Before even thinking about yes/no dialog, read
http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf and other
things on http://www.cs.auckland.ac.nz/~pgut001/

Best,

Mat?j

[brad longo]

Post by Matej Cepl

Post by Mike Chambers
They get a little question stating this program wants to run,
do you give it permission.

And yes, that's the reason why Vista is still totally broken
security-wise. Before even thinking about yes/no dialog, read
http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf and other
things on http://www.cs.auckland.ac.nz/~pgut001/
Best,
Mat?j

Is disabling selinux yourself really that difficult? Also I know from
experience that selinux wasn't that great in the past, and since I
started using Fedora I have always disabled it without thinking whenever
I updated. Recently though when I updated to Fedora 9 I just left it
alone, and now I sometimes even forget that its there. I have had no
issues with it at all. The way I see it, if its not broken why touch
it? It only increases security.

--Brad

[Stephen John Smoogen]

Post by Alan Cox

Post by Jon Masters
I think the only way to "fix" it for the foreseeable future is to
simplify policy, so that only a very limited set of services are
confined. Then, when the graphical tools and user experience have
eventually caught up, it'll be trivial to switch policy again.

How will you know you have "fixed" it if you have the bits in question
turned off - you won't. You have no meaningful way to make progress.
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 probably also remembers the same arguments being used for DAC
security (I remember them from gnu.* and comp.unix*) from long ago.
15+ years ago there were lots of systems that had the root password in
the motd because well DAC got in the way of getting stuff done that
was normally done and you might as well have the root password if you
wanted to 'fix' it. Several of these systems usually also had a short
hand script that would setuid the program you wanted and setuid it
back to the old permissions after you ran it. They also usually also
had files with all the social security numbers, etc of every student
etc..

The number of desktops and servers where I find firewalls turned off
at install is still staggering. Most of them are the ones where they
ran into some problem, googled and saw turn it off as the answer and
did so. The number of desktops where the person runs everything as
root is also amazing.. and boy do they now get ticked at that "You are
running things at root" message.

In the end, I don't see a fix.. people want things like their car.
Turn the key, go, in the same way every car they ever liked driving
has been. They hate it when they find the car has a governor to keep
it from going 150+, ABS to change braking behaviour, airbags,
front-wheel versus rear-wheel, transmission gearing changes, etc etc.
They really don't care one-whit if any of those changes make them
safer because they can't perceive it (and if any of those safety
devices go 'wrong' are more adamant that it was a wrong idea in the
first place, etc etc.)

Post by Alan Cox
This is the same thing ..
As to Setroubleshoot it would be nicer if it spoke more "end user" ese and
could prompt/fix common mislabelling (eg html files)
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Bruno Wolff III]

On Wed, Jul 02, 2008 at 17:16:10 -0400,

Post by Alan Cox
"Shall I enable the airbag ?"

That one I'd actually like.

[jcvlz]

It sounds like this issue has more to do with how easily an "average"
end user can admin/modify selinux and it's policies through a GUI
interface. So what about extending the functionality of one of the
gui apps?

i.e.
-If setroubleshoot is not part of the base package, include it and
have it turned on by default
-Add audit2allow/audit2why functionality to setroubleshoot
-Simplify the details section of setroubleshoot to be more
meaningful to end-users

FWIW - I'm for keeping selinux enforcing by default, but could
definitely see where end-users could be running into issues.


Juan Velez

[Alan Cox]

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Knowing what it is isn't sufficient - they must know enough to make a meaningful
risk analysis fo the decision. Very few users I suspect are in that position.

[James Morris]

Post by Alan Cox
Knowing what it is isn't sufficient - they must know enough to make a meaningful
risk analysis fo the decision. Very few users I suspect are in that position.

This is quite a significant problem, as people tend to underestimate
negative risk and overestimate positive risk (according to "Prospect
Theory").

And as the odds increase in each direction, people increasingly mis-judge
them. e.g. people believe they'll win the lottery but figure they don't
need a motorcycle helmet.

Bruce Schneier recently discussed the topic:
http://www.schneier.com/blog/archives/2008/05/how_to_sell_sec.html

The only way to really make progress in improving security is to make it a
standard part of the computing landscape; for it to be ubiquitous and
generalized, which is the aim of the SELinux project.

Having a separate "secure" version or option will not work, as proven many
times over with the trusted Unix variants which are essentially forks of
their respective mainline products.

Avoiding the whole issue will also not work, as DAC security simply cannot
provide adequate protection in a globally networked environment. The
rationale for MAC has been made very clear in an NSA paper, the reading of
which I think is essential for any informed discussion on the issue:

http://www.nsa.gov/selinux/papers/inevitability/

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.



- James

[Dave Airlie]

Post by James Morris

Post by Alan Cox
Knowing what it is isn't sufficient - they must know enough to make a meaningful
risk analysis fo the decision. Very few users I suspect are in that position.

This is quite a significant problem, as people tend to underestimate
negative risk and overestimate positive risk (according to "Prospect
Theory").
And as the odds increase in each direction, people increasingly mis-judge
them. e.g. people believe they'll win the lottery but figure they don't
need a motorcycle helmet.
http://www.schneier.com/blog/archives/2008/05/how_to_sell_sec.html
The only way to really make progress in improving security is to make it a
standard part of the computing landscape; for it to be ubiquitous and
generalized, which is the aim of the SELinux project.
Having a separate "secure" version or option will not work, as proven many
times over with the trusted Unix variants which are essentially forks of
their respective mainline products.
Avoiding the whole issue will also not work, as DAC security simply cannot
provide adequate protection in a globally networked environment. The
rationale for MAC has been made very clear in an NSA paper, the reading of
http://www.nsa.gov/selinux/papers/inevitability/
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.

That's all nice and all, but really SELinux on by default has never
worked on a Fedora gold release, there is always some path through some
program that didn't get tested, how about you guys try and come up with
a way to solve those problems in advance or at least give developers
some tools so regressions in SELinux policy can be tracked.

Like we have rpmdiff and that other internal rpm thingy for RHEL,
perhaps SELinux team could construct a similiar tool that says your new
package is going to violate policy where your old package didn't.

Relying on users to mail us the contents of some pop-up dialog box is
ass. Ask Dr. Watson.

Dave.

[James Morris]

Post by Dave Airlie
That's all nice and all, but really SELinux on by default has never
worked on a Fedora gold release, there is always some path through some
program that didn't get tested, how about you guys try and come up with
a way to solve those problems in advance or at least give developers
some tools so regressions in SELinux policy can be tracked.
Like we have rpmdiff and that other internal rpm thingy for RHEL,
perhaps SELinux team could construct a similiar tool that says your new
package is going to violate policy where your old package didn't.

I'm not sure that's feasible -- if it were that simple, the policy would
write itself. Possibly something can be done, but it won't make up for
lack of testing. I know of several major packages which cannot possibly
have been tested with SELinux before being shipped.

Even if all people do is enable SELinux for ten minutes at some stage
prior to release, and file the audit logs into a bz, that would probably
fix most of these issues.

Perhaps we should be thinking in terms of establishing the practice of
developers doing all development with SELinux enabled and in enforcing
mode, providing tools to support that. e.g. implement a wrapper for
automated policy module generation for devel use only, and the developer
submits the generated module to the SELinux team at some point, like
during an alpha release, and an "official" policy module is developed from
that and committed to rawhide. i.e. incorporate SELinux policy
development into the overall development process with the package
developers involved from the start and getting assistance from the
SELinux folk.


- James

[Matej Cepl]

Post by Dave Airlie
Relying on users to mail us the contents of some pop-up dialog
box is ass. Ask Dr. Watson.

With the XML-RPC being available, I would think that something
similar to what bug-buddy does -- i.e., automatical creation of
a bug by pressing one button, should be possible. Of course, it
requires some bug triaging before Dan even sees the bug, but it
should be doable.

Best,

Mat?j

[Arjan van de Ven]

On Sat, 05 Jul 2008 01:36:05 +0200

Post by Matej Cepl

Post by Dave Airlie
Relying on users to mail us the contents of some pop-up dialog
box is ass. Ask Dr. Watson.

With the XML-RPC being available, I would think that something
similar to what bug-buddy does -- i.e., automatical creation of
a bug by pressing one button, should be possible. Of course, it
requires some bug triaging before Dan even sees the bug, but it
should be doable.

sounds like something similar to kerneloops.org could be in place....

[jeff]

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Perhaps by way of a compromise it could be noted in the installation docs if
you want to disable SELinux you should add "linux selinux=0" to the boot: line
of the install CD. This would make the option available the same way that
xfs/reiserfs/jfs are available. The user isn't confronted with it, but Linus[1]
can then easily disable it at install time.

For this to work, anaconda would have to then pass the selinux=0 to grub.

Benefits:
* Users aren't confronted with dialog box they don't understand
* Power users that "know" they don't need/want selinux still have it available
* Only needs small change to anaconda
* All win

Drawbacks:
* Nonewhatsoever ;)

-Jeff

[1] https://bugzilla.redhat.com/show_bug.cgi?id=439858

[Rahul Sundaram]

Post by jeff

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Perhaps by way of a compromise it could be noted in the installation
docs if you want to disable SELinux you should add "linux selinux=0" to
the boot: line of the install CD. This would make the option available
the same way that xfs/reiserfs/jfs are available. The user isn't
confronted with it, but Linus[1] can then easily disable it at install
time.

The policy has already been fixed and swfdec isn't installed by default
so there is no need to do that. It is already documented in the SELinux
FAQ now but installation guide can have a reference too. File a RFE.

Rahul

[max bianco]

On Mon, Jul 7, 2008 at 3:58 AM, Rahul Sundaram

Post by jeff

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Perhaps by way of a compromise it could be noted in the installation docs
line of the install CD. This would make the option available the same way
that xfs/reiserfs/jfs are available. The user isn't confronted with it, but
Linus[1] can then easily disable it at install time.

The policy has already been fixed and swfdec isn't installed by default so
there is no need to do that. It is already documented in the SELinux FAQ now
but installation guide can have a reference too. File a RFE.
Rahul

Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

Max

[Rahul Sundaram]

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

Sure, there is. Refer

https://fedoraproject.org/wiki/SELinux/FAQ

Rahul

[Denis Leroy]

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

that doesn't make *any* sense

[max]

Post by Denis Leroy

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

that doesn't make *any* sense

It make as much sense as the rest of this thread and what it proposes.
Yes I realize this is extreme but no more extreme in my view than
disabled by default or offering the option at install time. There is
already a way to disable it if you know enough and if you don't then you
need it on anyway. For crying out loud my girlfriend uses Fedora, her
use is much closer to average than any of the rest of us and SELinux has
*never* caused her a problem. My mother, as computer illiterate as they
come( no disrespect intended Mom) does not have any problems. This
conversation is pointless, I see a hundred posts about people
complaining about people discussing things like the GPL on a developer's
list, a subject quite relevant in my view, but when the idea of
disabling practically the only security present on the system is brought
up , it actually gets entertained? Disable it?!?What?!? It seems to me
that entirely too many people have their priorities seriously out of
whack. In today's world, security better be the first consideration. The
internet is a war zone. Any scum bag with a linux box can make a snazzy
web page and lure in the unsuspecting. I don't think anyone is claiming
SELinux is the be-all end-all of security tools but considering its one
of the very few *real* security tools available I don't see how this
thread has managed to get this long. I've said my bit.

Max

[Denis Leroy]

Post by max

Post by Denis Leroy

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

that doesn't make *any* sense

It make as much sense as the rest of this thread and what it proposes.
Yes I realize this is extreme but no more extreme in my view than
disabled by default or offering the option at install time. There is
already a way to disable it if you know enough and if you don't then you
need it on anyway. For crying out loud my girlfriend uses Fedora, her
use is much closer to average than any of the rest of us and SELinux has
*never* caused her a problem. My mother, as computer illiterate as they
come( no disrespect intended Mom) does not have any problems. This
conversation is pointless, I see a hundred posts about people
complaining about people discussing things like the GPL on a developer's
list, a subject quite relevant in my view, but when the idea of
disabling practically the only security present on the system is brought
up , it actually gets entertained? Disable it?!?What?!? It seems to me
that entirely too many people have their priorities seriously out of
whack.

you are COMPLETELY missing the point. In some context, security is
irrelevant. Like that Fedora system we use in our lab at work for
bringup testing: it doesn't even have a network card.

some people thing that criticizing SELinux installation policy (not
SELinux itself mind you, which is a useful thing) == saying "security is
not important". This is ridiculous.

The only scenario I can think of where SELinux disabled installation
would be forcefully prohibited would be, say, a custom Fedora spin
targeted at employees or students where you don't want some smart guy to
disable it (because that would mean your job)...

[max]

Post by Denis Leroy

Post by max

Post by Denis Leroy

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

that doesn't make *any* sense

It make as much sense as the rest of this thread and what it proposes.
Yes I realize this is extreme but no more extreme in my view than
disabled by default or offering the option at install time. There is
already a way to disable it if you know enough and if you don't then
you need it on anyway. For crying out loud my girlfriend uses Fedora,
her use is much closer to average than any of the rest of us and
SELinux has *never* caused her a problem. My mother, as computer
illiterate as they come( no disrespect intended Mom) does not have any
problems. This conversation is pointless, I see a hundred posts about
people complaining about people discussing things like the GPL on a
developer's list, a subject quite relevant in my view, but when the
idea of disabling practically the only security present on the system
is brought up , it actually gets entertained? Disable it?!?What?!? It
seems to me that entirely too many people have their priorities
seriously out of whack.

you are COMPLETELY missing the point. In some context, security is
irrelevant. Like that Fedora system we use in our lab at work for
bringup testing: it doesn't even have a network card.

The last time I looked a computer without internet access is completely
useless to the average user. What do you think the majority of people
are doing with their computers? playing solitaire? No network card is
not the norm. Anyway what's to stop some disgruntled employee from
quietly loading a program onto your test box that will have you
scratching your head for days because you can't imagine what might be
wrong. I think you have missed my point, probably because I failed to
express it adequately so I will drop it. This insanity isn't worth
discussing anyway.

[Arthur Pemberton]

Post by max

Post by Denis Leroy

Post by max

Post by Denis Leroy

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

that doesn't make *any* sense

It make as much sense as the rest of this thread and what it proposes.
Yes I realize this is extreme but no more extreme in my view than disabled
by default or offering the option at install time. There is already a way to
disable it if you know enough and if you don't then you need it on anyway.
For crying out loud my girlfriend uses Fedora, her use is much closer to
average than any of the rest of us and SELinux has *never* caused her a
problem. My mother, as computer illiterate as they come( no disrespect
intended Mom) does not have any problems. This conversation is pointless, I
see a hundred posts about people complaining about people discussing things
like the GPL on a developer's list, a subject quite relevant in my view, but
when the idea of disabling practically the only security present on the
system is brought up , it actually gets entertained? Disable it?!?What?!? It
seems to me that entirely too many people have their priorities seriously
out of whack.

you are COMPLETELY missing the point. In some context, security is
irrelevant. Like that Fedora system we use in our lab at work for bringup
testing: it doesn't even have a network card.

The last time I looked a computer without internet access is completely
useless to the average user. What do you think the majority of people are
doing with their computers? playing solitaire? No network card is not the
norm. Anyway what's to stop some disgruntled employee from quietly loading a
program onto your test box that will have you scratching your head for days
because you can't imagine what might be wrong. I think you have missed my
point, probably because I failed to express it adequately so I will drop
it. This insanity isn't worth discussing anyway.

I like SELinux due to the fact that is has personally saved my sorry
ass at least once. However, I feel that users should be given the
opportunity to disable SELinux at will. In my case, I disable SELinux
on my firewalled, natted desktop.

[Jeff Spaleta]

Post by max
The last time I looked a computer without internet access is completely
useless to the average user. What do you think the majority of people are
doing with their computers? playing solitaire?

No the are playing Liquid War!


-jef"I should get the wii-mote working as an input on my laptop and
hack liquidwar to use it as an input device"spaleta

[Denis Leroy]

Post by max
The last time I looked a computer without internet access is completely
useless to the average user. What do you think the majority of people
are doing with their computers? playing solitaire? No network card is
not the norm. Anyway what's to stop some disgruntled employee from
quietly loading a program onto your test box that will have you
scratching your head for days because you can't imagine what might be
wrong.

I have a media server here with Fedora on it. Just a storage box with
MP3s on it. It has no direct connectivity to the net, as such it has no
root password, no firewall and no SELinux. Adding any of these would be
a complete waste of time and disk space since they offer no protection
against an intruder with direct physical access and a screwdriver. OTOH,
the filesystem is encrypted.

I'm not sure what you're arguing for. You're saying security is
important. I fully agree. You're saying SELinux is important. I fully
agree. You're saying SELinux should be enabled by default on our Desktop
installation. I fully agree. Fedora is probably (? does anyone know for
sure) the only desktop distro that does this by default.

However sabotaging the installer to make it impossible for people to
disable it at installation, now that's where I say "that doesn't make
any sense", cf my original email.

[Bruno Wolff III]

On Mon, Jul 07, 2008 at 04:32:29 -0400,

Post by max bianco
Can an option to completely disable the ability to disable SELinux be
added? I'd rather there was no way to turn it off at all.

You can already do this post install, so that the only way to disable involves
rebooting. And you can make it so that someone has to physically touch the
box and do something extreme (pull a disk, the cmos battery or something
similar) to be able to disable it.

[Ingvar Hagelund]

This would need a bit more hacking to Anaconda, but what about an
"Expert security settings" dialog with a note that most users should
leave these untouched. In this dialog, experienced sysadmins may
switch off selinux, tweak or disable the firewall, and praps other
stuff too.

Ingvar
--
Buddha wears an iPod



Den 7. juli. 2008 kl. 09.58 skrev Rahul Sundaram <sundaram at fedoraproject.org

Post by Rahul Sundaram

Post by jeff

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give,
including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Perhaps by way of a compromise it could be noted in the
installation docs if you want to disable SELinux you should add
"linux selinux=0" to the boot: line of the install CD. This would
make the option available the same way that xfs/reiserfs/jfs are
available. The user isn't confronted with it, but Linus[1] can then
easily disable it at install time.

The policy has already been fixed and swfdec isn't installed by
default so there is no need to do that. It is already documented in
the SELinux FAQ now but installation guide can have a reference too.
File a RFE.
Rahul
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[jeff]

Post by Rahul Sundaram

Post by jeff

Post by Jesse Keating

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

If they don't know what it is, how are they supposed to decide to shut
it off or not?

Perhaps by way of a compromise it could be noted in the installation
docs if you want to disable SELinux you should add "linux selinux=0"
to the boot: line of the install CD. This would make the option
available the same way that xfs/reiserfs/jfs are available. The user
isn't confronted with it, but Linus[1] can then easily disable it at
install time.

The policy has already been fixed

Which policy? The no dialog box in anaconda? I'm not saying it should be
restored. I'm offering a workaround with *no* dialog box, default installs get
SELinux, but users that *know* they don't want SELinux still have an option for
it at install time.

Post by Rahul Sundaram
and swfdec isn't installed by default so there is no need to do that.

I didn't mean to drag swfdec into this--I pointed at that bug for this quote
(which I should have made more clear):

torvalds at linux-foundation.org wrote[1]:
"Normally I just turn selinux off"

Post by Rahul Sundaram
It is already documented in the SELinux
FAQ now but installation guide can have a reference too.

Well, it would require *slightly* more than just that: like a couple lines in
anaconda to make sure that selinux=0 got passed to grub.conf. That's it though.
Very very unobtrusive.

Post by Rahul Sundaram
File a RFE.

Done.

https://bugzilla.redhat.com/show_bug.cgi?id=454338


-Jeff

[1] https://bugzilla.redhat.com/show_bug.cgi?id=439858#c31

[Rahul Sundaram]

Post by jeff

Post by Rahul Sundaram
The policy has already been fixed

Which policy?

SELinux policy of course. The bug your referenced has more details.

Post by jeff
I didn't mean to drag swfdec into this--I pointed at that bug for this

Developers frequently do turn off on all sort of security measures
including firewalls just to avoid having to debug such issues. It is not
very relevant for regular users.

Rahul

[jeff]

Post by Rahul Sundaram

Post by jeff

Post by Rahul Sundaram
The policy has already been fixed

Which policy?

SELinux policy of course. The bug your referenced has more details.

Well, that's a broad policy. I'm just talking about the ability to disable it,
not removing it altogether or whatever. The policy isn't "no one should be able
to disable this" is it? I think not. The current policy is to allow users to
disable it if they want, correct? Currently this is only available
post-install. There are many users that want it at install time too, which was
previously available.

I'm not asking for a change to selinux policy.

Post by Rahul Sundaram

Post by jeff
I didn't mean to drag swfdec into this--I pointed at that bug for this

Developers frequently do turn off on all sort of security measures
including firewalls just to avoid having to debug such issues. It is not
very relevant for regular users.

I'm not talking about regular users. I'm talking about users that also use
things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux.

-Jeff

[Rahul Sundaram]

Post by jeff
Well, that's a broad policy. I'm just talking about the ability to
disable it, not removing it altogether or whatever.

That wasn't clear from your reference to the bugzilla report which was
very specifically due to the interactions between swfdec being installed
by default and issues with SELinux policy which has subsequently been
fixed.

Post by jeff
I'm not talking about regular users. I'm talking about users that also
use things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux.

All filesystems that support extended attributes including the above
does support SELinux too so that choice shouldn't matter much. If users
prefer to disable it for other reasons, that should be supported which
the RFE you filed should cover.

Rahul

[jeff]

Post by Rahul Sundaram

Post by jeff
Well, that's a broad policy. I'm just talking about the ability to
disable it, not removing it altogether or whatever.

That wasn't clear from your reference to the bugzilla report which was
very specifically due to the interactions between swfdec being installed
by default and issues with SELinux policy which has subsequently been
fixed.

I'm not trying to talk about swfdec *AT ALL*. I referenced that bug report to
show that even Linus Torvalds himself typically disables selinux (along with
probably hundreds of thousands of other people).

Post by Rahul Sundaram

Post by jeff
I'm not talking about regular users. I'm talking about users that also
use things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux.

All filesystems that support extended attributes including the above
does support SELinux too so that choice shouldn't matter much. If users
prefer to disable it for other reasons, that should be supported which
the RFE you filed should cover.

Sorry I'm not being very clear.

I'm not trying to talk about how those filesystems and selinux interact.

I was merely pointing out reiserfs/jfs/xfs since they are supported in a
similar way that I think disabling selinux could be supported. I simply meant,
"Hey, there are obscure filesystem setups which are supported for power users
via the 'boot:' line--we could do something similar with selinux".



But the proposal is getting confused with these side topics.


The proposal is simply to satisfy the people that want SELinux by default and
the people that don't want SELinux at install time. It meets the needs of both
with minimal changes to fedora.


-Jeff

[David Nielsen]

Post by jeff

Post by Rahul Sundaram

Post by jeff
Well, that's a broad policy. I'm just talking about the ability to
disable it, not removing it altogether or whatever.

That wasn't clear from your reference to the bugzilla report which was
very specifically due to the interactions between swfdec being installed by
default and issues with SELinux policy which has subsequently been fixed.

I'm not trying to talk about swfdec *AT ALL*. I referenced that bug report
to show that even Linus Torvalds himself typically disables selinux (along
with probably hundreds of thousands of other people).

Because Linus Torvalds perfectly describes our average user?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080707/79f25031/attachment.html

[jeff]

Post by jeff
Well, that's a broad policy. I'm just talking about the
ability to disable it, not removing it altogether or whatever.
That wasn't clear from your reference to the bugzilla report
which was very specifically due to the interactions between
swfdec being installed by default and issues with SELinux policy
which has subsequently been fixed.
I'm not trying to talk about swfdec *AT ALL*. I referenced that bug
report to show that even Linus Torvalds himself typically disables
selinux (along with probably hundreds of thousands of other people).
Because Linus Torvalds perfectly describes our average user?

Again, I'm not talking about the average user.

I'm talking about the same class of users that also know that they want things
like xfs/jfs/reiserfs.

Or is Fedora only for the "average user"? I would presume fedora would also
want to satisfy non-average users, such as developers.

You comment is pure noise.

-Jeff

[Rahul Sundaram]

Post by jeff
I'm not trying to talk about swfdec *AT ALL*. I referenced that bug
report to show that even Linus Torvalds himself typically disables
selinux (along with probably hundreds of thousands of other people).

What Linus does hardly represents the case for the average end user and
citing him as an example makes no sense to me as I explained earlier. We
all don't choose our text editor, desktop environment or system
architecture based on that either.

Post by jeff
Sorry I'm not being very clear.

Post by jeff
The proposal is simply to satisfy the people that want SELinux by

default and the people that don't want SELinux at install time. It
meets the needs of both with minimal changes to fedora.

Alright.

Rahul

[Alan Cox]

Post by Rahul Sundaram
What Linus does hardly represents the case for the average end user and
citing him as an example makes no sense to me as I explained earlier. We
all don't choose our text editor, desktop environment or system
architecture based on that either.

"Don't bother shipping CVS I'll just write my own version control" ;)

[jeff]

Post by Alan Cox

Post by Rahul Sundaram
What Linus does hardly represents the case for the average end user and
citing him as an example makes no sense to me as I explained earlier. We
all don't choose our text editor, desktop environment or system
architecture based on that either.

"Don't bother shipping CVS I'll just write my own version control" ;)

Heh. And thank god he did! /me <hearts> git ;)


But my proposal threadlet now has 9 posts but zero comments on the actual
proposal. Everything has been about side issues and such.

Mr. Cox, do you see and *technical* problems with the selinux=0 passed to
anaconda passed to grub.conf proposal?

Thanks,

-Jeff

[drago01]

The whole discussion is pointless ... the option is not gone you *can*
disable it after install if you want.
Let me repeat this again you *can* still disable it if you want,
nobody is forcing you to use it.
Asking everything at install time is just wrong and confusing for average users.
Add adding some hidden anaconda option only to save 1-2min for people
that want to disable something doesn't make sense to me.
If you know what selinux is, and have reasons to disable it isn't hard to do so.

[jeff]

Post by drago01
The whole discussion is pointless ... the option is not gone you *can*
disable it after install if you want.

You *could* disable it at install time too, easily. It would likely install
faster as well.

Post by drago01
Let me repeat this again you *can* still disable it if you want,
nobody is forcing you to use it.

Yes, I know that.

Post by drago01
Asking everything at install time is just wrong and confusing for average users.

I agree. That's why my proposal doesn't ask anything at install time, thus the
average user doesn't have to confront the issue. As a parallel example, I offer
how xfs/jfs/reiserfs are available, but the user isn't prompted.

In my solution the average user wouldn't be confused at all because they
wouldn't see it--just like they don't see xfs/jfs/reiserfs options.

Post by drago01
Add adding some hidden anaconda option only to save 1-2min for people
that want to disable something doesn't make sense to me.

Well, it would actually save more than 1-2 min. And it really isn't a hidden
anaconda option, it's just having anaconda pass that to grub. Anaconda already
has some support for this, it just doesn't pass it to grub. It may be a simple
one-liner in anaconda.

-Jeff

[drago01]

Post by jeff

Post by drago01
The whole discussion is pointless ... the option is not gone you *can*
disable it after install if you want.

You *could* disable it at install time too, easily. It would likely install
faster as well.

You could set stuff like display resolution at install time too .. and
we got rid of it, which is a good thing imho.
Why should it be faster?

Post by jeff

Post by drago01
Let me repeat this again you *can* still disable it if you want,
nobody is forcing you to use it.

Yes, I know that.

Fine, where is the problem than?

Post by jeff

Post by drago01
Asking everything at install time is just wrong and confusing for average users.

I agree. That's why my proposal doesn't ask anything at install time, thus
the average user doesn't have to confront the issue. As a parallel example,
I offer how xfs/jfs/reiserfs are available, but the user isn't prompted.
In my solution the average user wouldn't be confused at all because they
wouldn't see it--just like they don't see xfs/jfs/reiserfs options.

Which shouldn't be the case but that's a different topic.

Post by jeff

Post by drago01
Add adding some hidden anaconda option only to save 1-2min for people
that want to disable something doesn't make sense to me.

Well, it would actually save more than 1-2 min.

Well changing one line in /etc/selinux/config can't take much longer ;)

Post by jeff
And it really isn't a hidden
anaconda option, it's just having anaconda pass that to grub. Anaconda
already has some support for this, it just doesn't pass it to grub. It may
be a simple one-liner in anaconda.

Well the options get passed to the kernel not to anaconda, it just
parses (abuses) the kernel cmdline for stuff like this. (which isn't a
bad thing in general)

[jeff]

Post by drago01

Post by jeff
And it really isn't a hidden
anaconda option, it's just having anaconda pass that to grub. Anaconda
already has some support for this, it just doesn't pass it to grub. It may
be a simple one-liner in anaconda.

Well the options get passed to the kernel not to anaconda, it just
parses (abuses) the kernel cmdline for stuff like this. (which isn't a
bad thing in general)

I agree. And anaconda could just take one more step and add it to grub.conf ala
anaconda.id.bootloader.args.append. Voila, done. I don't think it is doing
this already, but I may be mistaken.

-Jeff

[Matthias Clasen]

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

[Jeff Spaleta]

Post by Matthias Clasen
I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

Are people more clever than me trying to work out a way to indicate if
a file is mislabeled via the file manager graphical interface? Is
that even technically possible? And if it is would would be a good UI
way to show that information without having to open up a properties
dialog window to see it?

-jef"votes for slowly pulsating red glow on the mislabeled file icon"spaleta

[seth vidal]

Post by Matthias Clasen

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

Where? I see it showing me what they are but I don't see how to change
them.

is it an option I have to enable?

-sv

[Matthias Clasen]

Post by seth vidal

Post by Matthias Clasen

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

Where? I see it showing me what they are but I don't see how to change
them.
is it an option I have to enable?

Ah, I think the fix for that narrowly missed F9.
I have it working on rawhide here.

[Jon Masters]

Post by Matthias Clasen

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

It displays the current context. I'm guessing if you're root at the time
then it probably allows you to change it, but that's not useful until
there's e.g. a PolicyKit hook that allows regular users to relabel.

Jon.

[Doug Ledford]

Post by Jon Masters

Post by Matthias Clasen

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

I don't disagree with the general sentiment that selinux is not a very
good fit for desktop users as it is today. But nautilus _does_ support
labeling of files via the right-click properties dialog.

It displays the current context. I'm guessing if you're root at the time
then it probably allows you to change it, but that's not useful until
there's e.g. a PolicyKit hook that allows regular users to relabel.

Well, that's just incredibly helpful when combined with the whole "you
should never, under any circumstances, run X windows as root" thread of
a few days ago ;-)
--
Doug Ledford <dledford at redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080702/fe5f025c/attachment.bin

[David Malcolm]

On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote:
[snip]

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

Sounds like a regression; this used to work fine (on this RHEL5 ~ FC6
box I can do this from the Permissions tab of the nautilus file
properties dialog, and watch the SELinux column of the nautilus List
View change).

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

What is this "kernel" thing? Why do I need it?

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Jon Masters
Hi folks,

<Snip>
.....
</Snip>

Post by Jon Masters
Cheers,
Jon.

As I see this there are 2 issues to address/improve...

First get rid of the false positives.

Dan does an exceptional work on fixing selinux reports.

The problem here is not that things don't get FIXED they
don't get reported.

This is something that Fedora-QA and testers community need to
step in and improve as in add to task list do a better jobs of testing and
filing reports against selinux both rawhide and update testers.

wwoods: Ping something to bring up on next meeting.

Second simplify the incident report to the desktop user as in noob it down
It's very good from an technical level but tells the noobster absolutely
nothing
he sees it as gibberish and thinks "where am I supposed to <click> now
to make this go away".

If he's offered an [ Disable ] button he will <click> it.

There is absolutely no need to disable selinux when an exception is
just what is wanted/needed :)

The report should maybe be something more in this direction...

$application is trying to do something it should not be doing..
This is what it try to do < Summarize of the incident>

[ Allow exception ] [ Show full incident report ].

Just my 2 cents..

Best regards
Johann B.

[Daniel P. Berrange]

Post by Jon Masters
*). A number of activities are not possible today, with SE Linux enabled
and enforcing on a default F9 installation. I can give examples -
downloading an ISO image and expecting to use it in virt-manager,
creating a virtual machine in a non-standard location, etc.

We are aware of those problems and have work in progress to fix them. If
you find problems, file bugs about them. Complaining about things not
working without filing bugs won't get us anywhere.

Daniel

[Casey Dahlin]

Post by Jon Masters
Hi folks,
I'd like to see the re-introduction of an option during (or shortly
after, i.e. during firstboot) installation to disable SELinux, or set it
*). A number of activities are not possible today, with SE Linux enabled
and enforcing on a default F9 installation. I can give examples -
downloading an ISO image and expecting to use it in virt-manager,
creating a virtual machine in a non-standard location, etc.

Well we should fix these issues then, shouldn't we?

Post by Jon Masters
*). Policy changes will randomly stop things from working that used to
work. Especially on the Desktop, where many possible code paths (SE
Linux works by denying until an exception is found and added to the
policy...requiring all code paths to be exercised) exist to do
something. I found this last week when VPNC randomly broke.

Yes. This is very true. By the same token, we should stop shipping the
kernel as well since config changes can break things.

Or we could just do our job and release better updates.

Post by Jon Masters
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.

Nautilus is deficient in many ways for administration. We can fix all of
them. Personally I think the first thing to fix in nautilus is the
"Permission denied" errors when operating as an unprivileged user and
trying to access files to which you don't have permission. We should be
offering to elevate the user through policy kit in these situations.

Post by Jon Masters
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.

These unsuspecting desktop users who don't know what SELinux is will
then be able to turn it off and freely run virtual machines to continue
their clustering simulations and live migration tests.

I have enough civility in me to carry out any discourse politely...once.
This is about the 950th "SELinux ate my baby, let's turn it off" thread.
What's supposed to be different THIS time?

--CJD

[Stewart Adam]

Post by Casey Dahlin
This is about the 950th "SELinux ate my baby, let's turn it off" thread.
What's supposed to be different THIS time?
--CJD

Nothing. But all these threads have summed up two major points:

* New users don't know what SELinux is, does, or why their app isn't working or has stopped
working. Moreover, many more users don't know how to find the source of the problem and
report it. So overall that makes Fedora look broken in _stable releases_.

* SELinux is an important aspect to security on a Linux PC and it _will not_ be disabled on
new installs. If it's broken, then it's the solution isn't to disable SELinux but to fix the
bug in the policy.

If we could get the documentation for setroubleshoot online, I'd be interested in helping write a
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.

Stewart

[Tom &quot;spot&quot; Callaway]

Post by Stewart Adam
setroubleshoot online

I misread this and thought, what a great idea! The selinux equivalent to
"kerneloops" would be really useful. :)

~spot

[Daniel J Walsh]

Post by Tom &quot;spot&quot; Callaway

Post by Stewart Adam
setroubleshoot online

I misread this and thought, what a great idea! The selinux equivalent to
"kerneloops" would be really useful. :)
~spot

I think this is exactly what we need.

[Stewart Adam]

Post by Tom &quot;spot&quot; Callaway

Post by Stewart Adam
setroubleshoot online

I misread this and thought, what a great idea! The selinux equivalent to
"kerneloops" would be really useful. :)
~spot

That's what I meant by "?report audit denials similar to how kerneloops does" ;)

Stewart

[Suren Karapetyan]

Post by Stewart Adam

Post by Tom &quot;spot&quot; Callaway

Post by Stewart Adam
setroubleshoot online

I misread this and thought, what a great idea! The selinux equivalent to
"kerneloops" would be really useful. :)
~spot

That's what I meant by "?report audit denials similar to how kerneloops does" ;)
Stewart

It would be great :)

[Suren Karapetyan]

Post by Jon Masters
Hi folks,
I'd like to see the re-introduction of an option during (or shortly
after, i.e. during firstboot) installation to disable SELinux, or set it
*). A number of activities are not possible today, with SE Linux enabled
and enforcing on a default F9 installation. I can give examples -
downloading an ISO image and expecting to use it in virt-manager,
creating a virtual machine in a non-standard location, etc.
*). Policy changes will randomly stop things from working that used to
work. Especially on the Desktop, where many possible code paths (SE
Linux works by denying until an exception is found and added to the
policy...requiring all code paths to be exercised) exist to do
something. I found this last week when VPNC randomly broke.
*). Tools like nautilus do not support labeling of files via the
right-click properties dialog (gnome VFS, etc.) so there is no easy way
for an end user who even understands part of this to fix context. This
is the number one reason why SELinux should not be enabled by default,
except on systems where there is an admin who can use chcon.
But there are numerous other justifications I could give, including my
personal belief that it's absolutely nuts to thrust SE Linux upon
unsuspecting Desktop users (who don't know what it is anyway) without
giving them the choice to turn it off.
Cheers,
Jon.

I just can't understand why it was removed.
If the answer is "to make it more secure" maybe we should also set root
fs encryption on by default and remove the checkbox?
It will become more secure...

[Andrew Farris]

Post by Suren Karapetyan
I just can't understand why it was removed.
If the answer is "to make it more secure" maybe we should also set root
fs encryption on by default and remove the checkbox?
It will become more secure...

You cannot immediately and easily turn that off after installation; you can with
selinux, so these are nowhere near the same thing.

[Suren Karapetyan]

Post by Andrew Farris

Post by Suren Karapetyan
I just can't understand why it was removed.
If the answer is "to make it more secure" maybe we should also set root
fs encryption on by default and remove the checkbox?
It will become more secure...

You cannot immediately and easily turn that off after installation; you can with
selinux, so these are nowhere near the same thing.

If You're smart enough to edit /etc/sysconfig/selinux and turn it off
You're not far from decrypting the system.

Anyway that wasn't even my main point.
Whom did that damned combo box upset so much it needed to be thrown
away?

EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.
It just makes the lives of some of us harder.

Post by Andrew Farris
--
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29

[Andrew Farris]

Post by Suren Karapetyan

Post by Andrew Farris

Post by Suren Karapetyan
I just can't understand why it was removed.
If the answer is "to make it more secure" maybe we should also set root
fs encryption on by default and remove the checkbox?
It will become more secure...

You cannot immediately and easily turn that off after installation; you can with
selinux, so these are nowhere near the same thing.

If You're smart enough to edit /etc/sysconfig/selinux and turn it off
You're not far from decrypting the system.
Anyway that wasn't even my main point.
Whom did that damned combo box upset so much it needed to be thrown
away?
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.
It just makes the lives of some of us harder.

I agree it should be there once installed, but I don't think it needs to be
there before/during installation. Installation should be simple and selinux is
anything but; asking whether to turn it on or off there makes no sense.

[Nils Philippsen]

Post by Suren Karapetyan
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.

Please don't confuse features with workarounds. I think it's acceptable
to kindly guide people into employing that workaround only if and when
they run into problems.

Nils

[Suren Karapetyan]

Post by Nils Philippsen

Post by Suren Karapetyan
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.

Please don't confuse features with workarounds.

I need ?neither SELinux nor encrypted rootfs on my desktop (at least
now). So I'm not trying to workaround SELinux related problems. I just
don't need it/them.

Post by Nils Philippsen
I think it's acceptable
to kindly guide people into employing that workaround only if and when
they run into problems.

??The border between kindly guiding and forcing is a bit too thin.

Post by Nils Philippsen
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

[Andrew Farris]

Post by Suren Karapetyan

Post by Nils Philippsen

Post by Suren Karapetyan
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.

Please don't confuse features with workarounds.

I need ?neither SELinux nor encrypted rootfs on my desktop (at least
now). So I'm not trying to workaround SELinux related problems. I just
don't need it/them.

I think its unfortunate that so many people believe SELinux is something 'for
the server' and not needed 'on the desktop'. That probably comes from the first
policy being deployed for server processes (if my memory serves correctly). I'm
not attacking your own position on this point Suren, but it is hard to
understand why you would think this unless not really understanding what SELinux
is meant to prevent.

The core developers working on SELinux have many times said the desktop is
precisely where it is most needed, especially confining browsers and plugins. I
think my personal information on my laptop is worth the extra security.

[Suren Karapetyan]

Post by Andrew Farris

Post by Suren Karapetyan

Post by Nils Philippsen

Post by Suren Karapetyan
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.

Please don't confuse features with workarounds.

I need ?neither SELinux nor encrypted rootfs on my desktop (at least
now). So I'm not trying to workaround SELinux related problems. I just
don't need it/them.

I think its unfortunate that so many people believe SELinux is something 'for
the server' and not needed 'on the desktop'. That probably comes from the first
policy being deployed for server processes (if my memory serves correctly). I'm
not attacking your own position on this point Suren, but it is hard to
understand why you would think this unless not really understanding what SELinux
is meant to prevent.
The core developers working on SELinux have many times said the desktop is
precisely where it is most needed, especially confining browsers and plugins. I
think my personal information on my laptop is worth the extra security.
--
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29

I'm no expert of SELinux, but I do have a good understanding of what it
does (at least currently).
And I agree: it's much more useful on the desktop than (BTW. don't laugh
at me when I mess with then/than) on the server (tune at a bit and it
can prevent social engineering).
But it's not useful to me.
And I understand I'm not the only user and it's OK if I don't like
something, others may like/want/need it.
But Fedora is about Freedom... freedom of choice among others.
And we are making increasingly harder to make non-standard choice.

The option to disable SELinux didn't create problems for anyone.
Experienced users knew what to do. And people not knowing what it is
just clicked 'Next'.

[Simo Sorce]

Post by Suren Karapetyan
The option to disable SELinux didn't create problems for anyone.
Experienced users knew what to do. And people not knowing what it is
just clicked 'Next'.

Wrong, it added yet another annoying mysterious choice for everybody.

You have all the tools to disable it later, it's not like we took away
the possibility to disable it, we just don't ask for it at installation
like we do not ask for other gazzilion configuration option at
installation time.

Everyone have some specific setting they change for the default right
after installation, should everyone get an option for it into the
install screen?

Let's be less selfish guys and look at the bigger picture.

If you know you don't need SELinux for whatever reason you can simply
disable it after installation (or in kickstart if you do automated
installations).

If you are a Fedora developer and disable it by default to "develop"
packages than I honestly think you are poorly executing your task.
You should set it to permissive only when you get some "access denied"
problem while testing the specific changes, and as soon as you are happy
with it and ready to push a new package, you should FIRST set? SELinux
back to Enalbled and (working with Dan if necessary) make sure your
package pass again all your tests.
Not doing so you are making a disservice to the Fedora community,
because if you don't test with SELinux on then you don't know if your
stuff will work with it enabled, and you will create a bad experience
for other developers and users.

Simo.

[Suren Karapetyan]

Post by Simo Sorce

Post by Suren Karapetyan
The option to disable SELinux didn't create problems for anyone.
Experienced users knew what to do. And people not knowing what it is
just clicked 'Next'.

Wrong, it added yet another annoying mysterious choice for everybody.

And because of that "?annoying mysterious choice" "everybody" just
couldn't install Fedora cause they didn't know what to do (i.e. click
Next)
That's the most horrible direction of reasoning.
With that we can easily remove every option from installation process.
(What's the point in asking what packages You want... You can
install/remove later... What's the point in changing default
partitioning... it's OK).

Post by Simo Sorce
You have all the tools to disable it later, it's not like we took away
the possibility to disable it, we just don't ask for it at installation
like we do not ask for other gazzilion configuration option at
installation time.

We're just make it harder to disable.
And we're doing it cause non-technical people don't like seeing
something they don't understand (and if You're not technical it will
happen quite often when working with PCs)

Post by Simo Sorce
Everyone have some specific setting they change for the default right
after installation, should everyone get an option for it into the
install screen?

SELinux isn't just a specific setting... It's a bit too big.
It's a feature 38.7% of systems in smolt have disabled...
Removing that combobox is like telling this 38.7% (203150)
"know what... the other 61.3% (321879) don't like *seeing* choice of
disabling SELinux during install... You'll have to do it after install."

Post by Simo Sorce
Let's be less selfish guys and look at the bigger picture.

That's what I do. :)

Post by Simo Sorce
If you know you don't need SELinux for whatever reason you can simply
disable it after installation (or in kickstart if you do automated
installations).
If you are a Fedora developer and disable it by default to "develop"
packages than I honestly think you are poorly executing your task.
You should set it to permissive only when you get some "access denied"
problem while testing the specific changes, and as soon as you are happy
with it and ready to push a new package, you should FIRST set? SELinux
back to Enalbled and (working with Dan if necessary) make sure your
package pass again all your tests.
Not doing so you are making a disservice to the Fedora community,
because if you don't test with SELinux on then you don't know if your
stuff will work with it enabled, and you will create a bad experience
for other developers and users.

Agree. It's like building a package and not checking if it works on
x86...
But I'm not a Fedora developer (yet).

Post by Simo Sorce
Simo.
--
Simo Sorce * Red Hat, Inc * New York

[Alan Cox]

Post by Suren Karapetyan
That's the most horrible direction of reasoning.

Its a very sane one

Post by Suren Karapetyan
With that we can easily remove every option from installation process.
(What's the point in asking what packages You want... You can
install/remove later... What's the point in changing default
partitioning... it's OK).

The partitioning needs to be queried because the layout cannot easily be
adjusted. The packages likewise although it is become less so and as the
post install tools get better there is a good argument for pushing that
choice ot later.

Post by Suren Karapetyan
SELinux isn't just a specific setting... It's a bit too big.
It's a feature 38.7% of systems in smolt have disabled...
Removing that combobox is like telling this 38.7% (203150)
"know what... the other 61.3% (321879) don't like *seeing* choice of

That's meaningless. What percentage of those systems are running with
the correct choice for their system ?

[Suren Karapetyan]

Post by Alan Cox

Post by Suren Karapetyan
That's the most horrible direction of reasoning.

Its a very sane one

Post by Suren Karapetyan
With that we can easily remove every option from installation process.
(What's the point in asking what packages You want... You can
install/remove later... What's the point in changing default
partitioning... it's OK).

The partitioning needs to be queried because the layout cannot easily be
adjusted. The packages likewise although it is become less so and as the
post install tools get better there is a good argument for pushing that
choice ot later.

Post by Suren Karapetyan
SELinux isn't just a specific setting... It's a bit too big.
It's a feature 38.7% of systems in smolt have disabled...
Removing that combobox is like telling this 38.7% (203150)
"know what... the other 61.3% (321879) don't like *seeing* choice of

That's meaningless. What percentage of those systems are running with
the correct choice for their system ?

That's a classic case of deciding what's best for the user instead of
asking him...

Anyway...
I tried to explain why I think the option must be there.
I'm done now. ;-)

[Alan Cox]

Post by Suren Karapetyan

Post by Alan Cox
That's meaningless. What percentage of those systems are running with
the correct choice for their system ?

That's a classic case of deciding what's best for the user instead of
asking him...

No. That was not the question I asked. I asked what percentage of those systems
are running the correct choice for the system.

The point I'm trying to make is that most users have no idea what the correct
risk/convenience trade off is for their system. They do not have the information
or take the time to think systemically about it and make an informed decision.

You can give users all the choice in the world but if they are confronted
at install time with questions that they do not know the answer to then the
result is not choice, it is randomness and a feeling of helplessness and
embarrasment on the part of the user.

Anyone with sufficient knowledge to make the assesment (and lots without)
know how to turn it off later.

Alan

[Simo Sorce]

Post by Alan Cox

Post by Suren Karapetyan

Post by Alan Cox
That's meaningless. What percentage of those systems are running with
the correct choice for their system ?

That's a classic case of deciding what's best for the user instead of
asking him...

No. That was not the question I asked. I asked what percentage of those systems
are running the correct choice for the system.
The point I'm trying to make is that most users have no idea what the correct
risk/convenience trade off is for their system. They do not have the information
or take the time to think systemically about it and make an informed decision.
You can give users all the choice in the world but if they are confronted
at install time with questions that they do not know the answer to then the
result is not choice, it is randomness and a feeling of helplessness and
embarrasment on the part of the user.
Anyone with sufficient knowledge to make the assesment (and lots without)
know how to turn it off later.

I fully agree with this line of reasoning.

Let's also try to make an example that should be easy to understand.

A choice must always be (as much as possible) something that the user at
least understand, the user may not care about, but understanding the
question makes him confident he knows what he is doing.

So if I ask: do you prefer apples or oranges ?

The specific user may not care, or may not have a preference, but he
clearly will understand the question and the problem space. In this case
a random choice is acceptable. (For someone that is allergic to oranges
or apples, the question is truly important too, and he knows exactly
what to choose).

Now if I ask: do you prefer foo or bar ?

How can someone answer to this ?
The only choice is random and not only the user feel confused about it,
and helpless, he will also probably feel anxious about what is the right
choice to make.

The SELinux question is like the latter for most people, and although
usually it seem bad to say, we actually know better what is the right
default choice (security over all is most important).
Power users that know what SELinux is, are the only one that would know
how to answer properly and consciously, they can easily make their
choice later and go disable SELinux, like a normal user instead would go
and change the desktop background to his liking.

Security by default is the best choice (and I wouldn't even ask about
the firewall assuming we still do it).

Simo.

[James Morris]

Post by Suren Karapetyan
SELinux isn't just a specific setting... It's a bit too big.
It's a feature 38.7% of systems in smolt have disabled...
Removing that combobox is like telling this 38.7% (203150)
"know what... the other 61.3% (321879) don't like *seeing* choice of
disabling SELinux during install... You'll have to do it after install."

Don't believe everything you read. The 61.3% figure is probably lower
than the real figure (by quite a lot) because many systems reported in
before SELinux was part of the smolt stats and are counted as "disabled".

(It would be nice to have a disclaimer on that page...)

Post by Suren Karapetyan

Post by Simo Sorce
Let's be less selfish guys and look at the bigger picture.

That's what I do. :)

Post by Simo Sorce
If you know you don't need SELinux for whatever reason you can simply
disable it after installation (or in kickstart if you do automated
installations).
If you are a Fedora developer and disable it by default to "develop"
packages than I honestly think you are poorly executing your task.
You should set it to permissive only when you get some "access denied"
problem while testing the specific changes, and as soon as you are happy
with it and ready to push a new package, you should FIRST set?? SELinux
back to Enalbled and (working with Dan if necessary) make sure your
package pass again all your tests.
Not doing so you are making a disservice to the Fedora community,
because if you don't test with SELinux on then you don't know if your
stuff will work with it enabled, and you will create a bad experience
for other developers and users.

Agree. It's like building a package and not checking if it works on
x86...
But I'm not a Fedora developer (yet).

Post by Simo Sorce
Simo.
--
Simo Sorce * Red Hat, Inc * New York

[Dmitry Butskoy]

Post by Suren Karapetyan
I'm no expert of SELinux, but I do have a good understanding of what it
does (at least currently).
And I agree: it's much more useful on the desktop than (BTW. don't laugh
at me when I mess with then/than) on the server (tune at a bit and it
can prevent social engineering).
But it's not useful to me.
And I understand I'm not the only user and it's OK if I don't like
something, others may like/want/need it.
But Fedora is about Freedom...

The real life is more prosaic. Fedora is more "sponsored by Red Hat"
rather than "totally" Freedom. And since RH had decided to promote
SELinux, we are compelled to follow them in this.

In other words -- It is not useful (for now) to propose an ability for
the average or even end user to install Fedora without SELinux. The
useful thing you can do is to write a faq or a wiki page with
description how to disable SELinux after install (and why it might be
useful at all), then point people to this resource (fe. at
http://www.fedorafaq.org ) ...

Post by Suren Karapetyan
And we are making increasingly harder to make non-standard choice.

Let's imagine a community of users, who need such a non-standard choices
in general. Could such a community be capable to provide their own Linux
distro, suitable for production environments? Seems no. It requires some
sponsor (or some commercial basis) for success.

Most cases the commerce in Linux is the support of users. And certainly
such a commerce "wants" the users to be as typical as possible. Hence it
seems not a good idea to allow them a lot of possible options, which
they could occasionally set and complicate the life of their supporting
engineer...

Certainly having the ability of non-standard choice is the good idea,
but the market does not like it... :-/


~buc

[Rahul Sundaram]

Post by Dmitry Butskoy
Certainly having the ability of non-standard choice is the good idea,
but the market does not like it... :-/

Maybe but there is certainly a market for things like software
appliances and custom spins.

http://fedoraproject.org/wiki/CustomSpins. Create your own distribution
and have fun.

Rahul

[Simo Sorce]

Post by Dmitry Butskoy
Let's imagine a community of users, who need such a non-standard choices
in general. Could such a community be capable to provide their own Linux
distro, suitable for production environments? Seems no. It requires some
sponsor (or some commercial basis) for success.

Debian does it without sponsors, heck they even almost voted to forbid
sponsorship at least once.

Post by Dmitry Butskoy
Most cases the commerce in Linux is the support of users. And certainly
such a commerce "wants" the users to be as typical as possible. Hence it
seems not a good idea to allow them a lot of possible options, which
they could occasionally set and complicate the life of their supporting
engineer...

Given Red Hat does not provide support for Fedora, you are completely
off the mark here. These choice are made on technical grounds by Fedora
developers and security conscious people.

Post by Dmitry Butskoy
Certainly having the ability of non-standard choice is the good idea,
but the market does not like it... :-/

It's not about Market or Red Hat, its about making a distribution that
can actually be used without going back to Linux From scratch, where you
have to build and configure each single piece of software on your own.

Simo.

[Nils Philippsen]

Post by Suren Karapetyan

Post by Nils Philippsen

Post by Suren Karapetyan
EVERYBODY who used to disable SELinux when the combo-box was there will
STILL disable it. We didn't get ANYTHING from removing that *feature*.

Please don't confuse features with workarounds.

I need ?neither SELinux nor encrypted rootfs on my desktop (at least
now).

Ironically, you'll only ever know whether you really need these two when
it's too late to make any decisions about it ;-).

Post by Suren Karapetyan
So I'm not trying to workaround SELinux related problems. I just
don't need it/them.

The same could be said about backups, firewalls, file permissions... or
just about anything else that has the potential of standing in your way
if something goes wrong with it.

Post by Suren Karapetyan

Post by Nils Philippsen
I think it's acceptable
to kindly guide people into employing that workaround only if and when
they run into problems.

??The border between kindly guiding and forcing is a bit too thin.

Nobody is forcing anybody here, after all you can easily switch it off
after installation. Or rather assist in improving it, even if you're not
entirely convinced of its usefulness for you personally ;-).

Post by Suren Karapetyan
[...]

Post by Nils Philippsen
SELinux isn't just a specific setting... It's a bit too big.

Post by Suren Karapetyan
It's a feature 38.7% of systems in smolt have disabled...
Removing that combobox is like telling this 38.7% (203150)
"know what... the other 61.3% (321879) don't like *seeing* choice of

That's meaningless. What percentage of those systems are running with
the correct choice for their system ?

That's a classic case of deciding what's best for the user instead of
asking him...

"Do you want to reduce the level of protection against malware and
computer criminals?" -- I'd say providing a good level of security by
default is objectively in the best interest of the user. Part of a
developer's job is actually making these decisions.

Nils