Marko Vojinovic <vvmarko <at> gmail.com> writes: > ... > > > > - it should be self-contained, installable and removable at any time, > > > > without influencing the system > > > > > > No serious security system can run entirely in userspace, they are all > > > implemented in the kernel. Standard UNIX permissions, firewall, SELinux, > > > you name it. That said, SELinux and firewall can be enabled/disabled by > > > root in a whim, while with the permissions system it is far from easy > > > (to disable it one would need to do a filesystem-wide chmod and chown, > > > while reenabling it afterwards is almost impossible). > > > > Have you seen how many people asked about it (hint: search Google) ? > > This has been debated to death on a lot of places, including this list. In a > nutshell, in all those debates I never saw anyone provide a reasonable > argument for wanting to completely remove SELinux. > Hi, Let me refresh some historical UNIX and Linux facts, which are known to many. The reasons that UNIX flourished, and later survived its self-inflicted wounds and a massive onslaught of Windows were: - its philosophy A kernel that was surrounded by flexibility in its system and user space (modular, single purpose, stand-alone utilities, easy to assemble and disassemble for a work to be done; a fruitful model for a broader, self-sustained, and extendable "ecological" space) - its people, a dedicated bunch of system professionals and users, adherents of that philosophy, ready to defend it in the business place and beyond and fight for what they believed was a superior idea Later came GNU and Linux movement, sharing these roots, but attacking the computing space from a different angle. We have a legacy of that successful UNIX philosophy that we should defend and extend. In the course of day-to-day dealings we loose the big picture. That's why we have to be reminded of it and be cleansed periodically. SELinux is wired to the system hopelessly (I am not familiar with AppArmor, Tomoyo, and other alternatives). This is a fascist model of security computing, and computing in general. We give you the tools, configure them for you (rules), all you have to do is to accept them, and become "comfortably numb" while we "relabel" your system for you as well. Around so tightly controlled system there is little space for extendability and alternative ecosystem. It is a classic unwanted consequence - a revolutionary (GNU, Linux) gains power, then becomes a dictator, then a tyrant. I am concerned about the trend. We pack all possible stuff into and make it inseparable from the kernel or other services, making it all intertwined hopelessly. This touches the Linux kernel as well. Linus had decided to follow the avenue of a big monolithic kernel, what may have been fully justified at that time, when the kernel was small and there was a lack of research and acceptable results in the area of micro kernels. But in the meantime, there have been many successful attempts at micro kernels, having equally good performance, architecture, etc. How is that relevant ? Well, have you noticed the underlying trend of modularity and offloading almost everything from kernel to user space ? Somehow I see an analogy to early UNIX times. I see it philosophically. Returning to the SELinux and security architecture. I think we may be heading in the wrong direction, compromising the UNIX philosophy, setting ourselves up for a wake up call due to difficult-to- maintain-and-extend kernel, system, and user spaces. I want to have a user-space real-time security service, with a smart and minimal system interface to the kernel or other services, but working as a stand-alone system utility that can be autonomous, modular, dynamically configurable, installable at any time, and removable at any time (completely and safely). Perhaps the time is now to stop, reflect, and get back on the right path. Btw, I appreciate your views. Thanks. JB -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
