On 10/18/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > Arthur Pemberton wrote: > > On 10/18/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > > > >> The place it can hurt is if it causes enough problems that some number > >> of users don't don't upgrade to the versions that use it or don't do > >> timely updates because they have a history of introducing new problems. > >> This drops your first and best line of defense. > > > > Les, please... this is a public list. Do not spread FUD... there is no > > history of SELinux updates causing problems. > > I'm speaking of fedora updates in general - and over a reasonable period > of time to call 'history'. If you look back to FC2 and FC3, you'll > certainly see a lot of complaints about SELinux updates breaking things. Well it would be nice if you diccuss one topic at a time, fedora updates is one matter, and SELinux history is another. Yes there were problems in FC2, FC3.. yes there are likely a few problems now. Yes it's going to take getting used to for some people. But we're up to F8 now. The problems, as far as I see, are a lot less - the main place I see valid SELinux problems are on the fedora-testing list. I'm on the SELinux list, and it's most queries about how to make SELinux do/allow something diff. And people can't get used to something if its not there. Your argument seems to be to remove, my argument is disable/don't enable if you don't like it. And if that's not your argument, you're arguing alongside those are calling for it's removal. The better thing would be to use your skills to find any and all left over bugs as the technology expands. > I have personally had multiple instances of devices that were not > supported in new versions, devices that changed names, breaking the > configurations, updates that installed kernels that would not boot > previously working systems, and the list is full of similar problems in > addition to the ones mentioning SELinux. That's two different issues. The former is regression issues - most of which aren't probably even directly the fault of Fedora. The later is SELinux having some bugs, or rather SELinux _rules_ having some bugs: selinux != selinux rules > >>> In a corporate environment it's obviously very different. Using > >>> different means of access control, using other layers of security such > >>> as SELinux, implementing physical security measures, are all things > >>> that need to be done, and properly. > >> If you are introducing Linux as something new you can do that. > >> Otherwise you have to be very careful not to break existing programs and > >> infrastructure with changes and updates. > > > > I don't see why there should be a requirement of being new. > > When you install a new system you get time to test it and nothing to > lose if it breaks. But assume your payroll system is running on > something that fails to boot or can't access it's data after you do an > update that is required for some security issue. Now what? Now you get fired for using a fast pace, mostly bleeding edge distro in your fiscally important production environment. > Or worse, > this could be some on-line, customer visible system that is the core of > your business. You get fired, and if I was your boss, sued. > >> If you want a distribution to be more secure in actual use, you have to > >> make it painless to update and never break anything that previously > >> worked - otherwise some number of people just won't do it. > > > > You do realise that there are different distros, and each has their > > niche. Fedora's niche is being fast pace, some would argue not fast > > enough. > > Perhaps, but if you want to deliver a product that does not have a > usable way to fix subsequently discovered security flaws after a sort > time then it should have an actual expiration date and self-destruct > instead of being left as easy prey for exploits that turn them into > zombie spam relays or worse. You know that's not really possible. People still run Windows 95, Fedora is the last place to look for expiring distros. > I, and probably most of the list members > here, understand the experimental nature of fedora and that it simply is > not suitable for anything that needs to be reliable over long periods of > time. I'm confused, your arguments were all based otherwise. > However, I don't think everyone who has installed fedora > understands that or the dangers of continuing to run any software beyond > the time it is supported with security updates. I don't know what anyone can do about that? Make people agree to an EULA that says they must upgrade every cycle? > And I am inclined to > believe the claims like this: > http://computerworld.co.nz/news.nsf/scrt/CD0B9D97EE6FE411CC25736A000E4723 > saying that there are large numbers of rootkitted linux boxes around > being used for evil purposes thet their owners don't even notice. I actually don't believe that news article at all. It's full of technical problems, but that's another story all together. > It > makes sense just because of the difficulty of keeping the installation > up to date over the life of a machine. It's not difficult. It's inconvenient for _some_ - not sure what percentage. > Fedora isn't the only disto in > this shape but it is probably one of the most popular with one of the > most difficult upgrade paths. Again, you're talking about Fedora upgrade paths in a thread about SELinux. We can't have a constructive discussion if you want to argue two different issues at the same time. > I wouldn't be surprised if there are > still large numbers of FC1 through FC5 installations in use A majority of those would be lazy/cheap/lying hosting companies who just throw Fedora on machines and then don't update them > because the > currently supported versions don't ensure (or even suggest) backwards > compatibility, in place upgrades, or even a convenient way to back out > to your previous version if you try an upgrade and find that it doesnt' > work with your hardware or applications. That's all true. But again, has little to do with the topic at hand. It isn't a technically trivial problem to get fast paced moving software to revert to any previous state, far less to do that reliably. If you're interesting a SIG to solve this problem, I don't think you will get any resistance. However, for a lot of the people doing the actual work, they don't seem to consider this a high priority problem, I myself don't. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com )
