Submitted by Red Hat has been working on an adaptation of Multi
Level Security called Multi
Category Security which is planned to be enabled by default on FC 5 along with other security enhancements
Red Hat has been working on an adaptation of Multi
Level Security called Multi
Category Security which is planned to be enabled by default on FC 5 along with other security enhancements
Multi level security has a certain resemblence with BSD secure levels and MAC.
More accurately, BSD secure levels and MAC have a resembelence to Linux MAC technologies, which are more mature.
Just to let you know there are BSD teams who keeps an eye on these features implemented by Red Hat. What that means is they want to improve their own code with new features.
The lesson given by Alan cox on BSD codes show that BSD is not perfect either no matter how hard the code is tighly worked with security in mind.
In other words, some BSD code are taken from Linux and vice versa.
See the section on security in http://fedoraproject.org/wiki/FC5Future for other proposed security features
See the section on security in http://fedoraproject.org/wiki/FC5Future for other proposed security features
I may be wrong but I think that you should also mention in that page about new GCC feature – Stack Smashing Protector. All new packages are built with this CFLAGS options -> “-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector –param=ssp-buffer-size=4” (at least in Fedora Extras
)
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html
http://sources.redhat.com/ml/libc-hacker/2005-06/msg00009.html
happy to see some proper MAC implementation being pushed by Red Hat. Linux native file ownership lacks big time (the most annoying part I find is the traditional linux file ownerships being only owner / group / others rwx permissions, which lacks big time compared to windows nt/xp where you can happily create multiple groups with different permissions)
If only selinux could be a bit more user-friendly, it is incredably complicated…
SELinux goes way, way beyond that. What you’re describing is Access Control Lists, which are a standard POSIX thing, and have been available in Linux for ages.
ACL have been there for a while, that’s true but most distros havn’t turned them on by default. Neither Gnome nor KDE have supported them. It is about time support for this ended up in the GUI, I think it will be in the next version of KDE.
Lets hope that this new MCS stuff gets some GUI as well. I don’t have much hope though as this is a Linux thing and Gnome and KDE,.. is targeted at a unixlike systems in general.
If only selinux could be a bit more user-friendly, it is incredably complicated…
It has been enabled by default in Fedora Core 3, 4 and RHEL 4. Targeted policy with SELinux booleans makes this process almost transparent to the end user
thing is that i find the rwx system far more user friendly then say the multi group system of microsoft.
atleast on a home desktop where i want root to have write rights while my normal user most of the time only needs read rights.
in a multimachine office enviroment i can see the point of this tho. and that just reinforces my belif that you cant make a single distro that can be used both at home and in the office, and dont even think about the server as the requirements are so diffrent.
thing is that i find the rwx system far more user friendly then say the multi group system of microsoft.
I wouldn’t say that. Giving specific users rights to do things without having to bogher with setting up special groups is rather straight forward unless you are a UNIX sysadmin.
You are right that there is no such thing as a one size fits all OS. Neither Linux nor WinXP is very suitable for home users. They are both full of features that are aimed at professional use.
so therefor i question why someone would want to have this on as default. allow it as a option in the installer but dont turn it on as default.
thing is that RWX is simple, does its job 9 times out of 10 and with the right use of some other unix tools, can be quite powerfull.
rather then setting up diffrent groups and user abilitys on diffrent files, duplicate the inode connection into diffrent folders and set access on those.
thats one of the strong points of unix style file systems, you can have the same file available under diffrent (or the same) names in diffrent parts of the file system.
that means that if you need to clean up some access rights all you need to do is unlink/delete said inode connection. only when all inode connections are removed is the file viewed as deleted
and for a home computer its so much easyer to understand that the owner have this set of rights on the file, members of group have this set of rights and everyone else have the third set of rights. its so small that it can even be displayed in the file manager window in detailed mode.
a acl on the other hand can take up quite a lot of space to view if the rights on a file are many and complex, but i fail to see an enviroment outside some very big group projects where this may be needed. for the rest the acl will most likely be overkill.
but still, the fedora crew can feel free to take it anywhere for what i care. i dont use the distro and dont plan on doing so. i just hope that this will not be the next big fad in distros…
so therefor i question why someone would want to have this on as default. allow it as a option in the installer but dont turn it on as default.
Security as a one off seperare product isnt really a good idea. The argument that home users dont need security features so therefor i question why someone would want to have this on as default. allow it as a option in the installer but dont turn it on as default. as much as a server implies that users dont care about their data which isnt true. The installer will provide an option to turn it off as much as it would provide a option to turn off a firewall but neither is recommended practise
Targeted SELinux policy is default in FC 3/4 and is transparent to the majority off the people. Great care has been taken to ensure that transition to MCS capability doesnt require a relabelling of the filesystem. If its transparent users who dont require this can simple opt to not use this capability instead of turning off the framework.
Calling it a fad undermines that enormous amount of work being done to enable such security improvements by default
and how fast can a untrained user fully undermine this security as he is having a hard time understanding how it works?
RWX works because its simple to understand. Read, Write, eXecute.
this stuff belongs in a office enviroment with a dedicated sysadmin. for a desktop install it will be overkill and will most likely create frustration or end up being undermined by some user that gives himself full access on all levels as everything else is to hard to understand.
i understand the work being done and i welcome it, but i dont feel it belongs in all scenarios that todays distros can be used in.
i worry that it will be included not because there is any realy need, but because it have become the buzzword feature of the month.
thing is that the more complex a security setup can be, the more brittle it is. even more so in semi- or un-trained hands.
hell, given how many there is that allready set 777 on all files with the classical controls i wonder what we will see when this is default…
<iand how fast can a untrained user fully undermine this security as he is having a hard time understanding how it works?[/i]
The worse the users can do is fall back on the classic DAC permissions which is the same as turning it off by default so it presents not additional security risks.
MCS policies use the existing kernel and MCS policy framework so its not bloat. Its transparent to end users so that it adds no additional complexity.
i understand the work being done and i welcome it, but i dont feel it belongs in all scenarios that todays distros can be used in.
Fedora by design is meant to provide such cutting edge innovative features. It might not fit in with other distributions design or goals but waiting for everyone to play catch up is ensuring that noone ever does it.
i worry that it will be included not because there is any realy need, but because it have become the buzzword feature of the month.
The basic concept of MLS is decades old. Traditionally people have been treating it as a niche market one off thing. Making it accessible and default in an mainstream product is the goal of MCS. Buzzword or not it serves a very real need for many users who had to pay thousands of dollars to get it before
thing is that the more complex a security setup can be, the more brittle it is. even more so in semi- or un-trained hands.
Very true but SELinux on the whole is a additional layer of security that works on top of the DAC (rwx) permissions set. So again you will be no worse off even if you relax it the policies to the highest possible extend. It is not brittle by any means. In fact many people have argued that its quite stringent. User space tools are getting more and more user friendly. one step at a time
hell, given how many there is that allready set 777 on all files with the classical controls i wonder what we will see when this is default…
ha. When writing such SELinux policies developers have constantly discovered poor security practises by many programs and fixed those helping users who dont use this at all. So if it does expose such poor practises like a 777 permission set then thats a good thing.
Unlike the DAC permission model, administrators can actually control the security of their systems through centralised SELinux policies instead of users doing a chown 777 on their own files accidentally or deliberately and exposing their data or opening up a security hole and thus ensuring the safety of the system
For home users MCS is completely transparent while targeted SELinux policies provide a additional security layer important to protect their information on the home directories
Access lists sound very powerful on paper. I have yet to see them used in practice.
You’ll get a job eventually, don’t worry.
🙂 good joke. I happen to have one. Though it does not involve changing access settings for files.
What I meant is – I have not seen much use of ACL in praxis. For example Windows. Not sure about XP, but in NT 4 and 2K, a normal user could write into a lot of system directories. Not even MS bothered to set up the permissions in a secure way – though they could.
In my company (which better remains nameless
, we used to have NT-based file servers. Most directories and files were writable by everyone.
I have seen people knowledgeable in application software (not Unix or other OSes) requesting 777 permissions for configuration files. At the very least, the executable bits should be dropped, but those people just don’t get it. Though they know a lot about other IT things.
I don’t meant to slander ACLs. They are very powerful. It’s just, I have no seen them used much, until now.
If you have a real-world example, I’d be relieved to hear it
.
See the section on security in http://fedoraproject.org/wiki/FC5Future for other proposed security features
Impressive list altogether,trusted x-windows..
The repository aware installer is a sweet improvement.I think it will be based on the users input of geographical location during install time,i hope they will give an option to choose from DAG,freshrpm,and such also?
Most important FC seems to listen (also) to its users that’s good.Less eye-candy but more things that really matter.Kudos to the devs.
“,i hope they will give an option to choose from DAG,freshrpm,and such also? ”
Core and Extras by default. Any custom repository on user choice is the goal. However this might only be a advanced option during the FC5 release. Anaconda requires massive changes to enable a yum backend.
As subject.
Fedora and Red Hat are doing excellent work at developing and integrating advanced security technologies into their systems. We already have much benefit from ExecShield, SELinux, PIE, NX, FORTIFY_SOURCE, malloc control pointer checks, mudflap. Good job!
Now if only they’d do more quality control and not rush releases, they’d actually have some decent software…
I am glad that they are planning to seriously trim down the number of CDs required though, as OT as that comment was…
I love fedora to death but honest to got it is a pain upgrading each time when my palm pilot gets blown away. For example in version 4.0, I had to remove Jpilot and install an old version plus all the old dependencies to get it to synch properly. I wish there was more hardware debugging with the most common devices before new versions were released.