Re: SELinux - a call for end-of-life.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux