On Thu, 2010-09-02 at 11:21 +0000, JB wrote: > 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 I agree with you about the extreme cost of the relabel problem, but that may be due to a lack of knowledge on my part. Relabeling the very small subset of space that is used for system and some of the more common applications is only going to take a couple of minutes, but if I have a few petabytes of disks attached, I do NOT want that walked under any circumstances by the relabeling process. Is there a way to restrict the relabeling to only a small subset of the filesystem? -- 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
