Submitted by In the past, SELinux has been critized for being too dificult to configure. To solve this, the SELinux policy editor was created: A GUI-oriented editor with a simplified policy description language (ala Apparmor). According to the announcement, this new version includes a much improved user interface and some improvements to the “Policy description language”.
SELinux Policy Editor 2.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m glad that this work is being done. I hope to see more distros and programs supporting SELinux out of the box. I believe its very important to keeping Linux secure.
I just installed this on one of my CentOS systems, and I am very impressed. The SPDL policy language that is used provides a simplicity that is comparable to the AppArmor policy language, but retains many of the good features of SELinux (such as port permissions, file labelling). I haven’t really used the graphical policy editor, but the command-line tools are great.
Looks like this is the “SELinux for mortals” many people have been waiting for.
The SPDL policy language that is used provides a simplicity that is comparable to the AppArmor policy language, but retains many of the good features of SELinux (such as port permissions, file labelling).
I think the project is very promising but AppArmor is still more comfortable to use.But Novell bought an ready concept from Immunix to be honest.
Edited 2006-07-08 16:44
For SELinux to be widely adopted, an “easy to use” gui policy editor is needed. Linux security in general already surpasses Microsoft Windows by leaps and bounds. With SELinux, hence Mandatory Access Control, it will be just that much further.
Microsoft Windows is EAL RSBACC certified, but doesn’t include anything close to LSPP (Labelled Security Protection Profiles). With the advent of Solaris 10 and the Trusted Extensions, Solaris supports RSBACC/LSPP. With SELinux, Linux supports RSBACC/LSPP.
‘nix seems to rely more on a proactive security mentality. Proactive security is using layers of security technologies to prevent exploits from happening. A good example would be RHEL with FORTIFY_SOURCE, Exec-Shield, SELinux, and a hardened glibc. Microsoft (in the past) has relied on reactive security ie patch and pray the 0day exploits don’t hit you.
Microsoft has nothing close to SELinux or Solaris’s Trusted Extensions allowing Labelled Security Protection Profiles. This gui SELinux policy editor with it’s new policy description language will likely be the thing to bring SELinux to the masses, just what Linux needs to be a more viable high security server operating system.
Unfortunatly this app is not compatible with any of the widely used policies or deployments of SELinux. It takes total control of the policy by changing all the filesystem labeling to something more path based (which is extremely broken btw, since, for example, remounting a drive at a different place totally changes the policy and the system can’t cope with it). It also removes large amounts of granularity that is potentially dangerous, for example, treating regular files and block devices the same.
On the other hand, solutions being worked on like selinux policy modules (already in FC5, going into RHEL5) bring policy management much closer to useful and provide a framework for more management down the line.
The reference policy (http://serefpolicy.sf.net) has made leaps and bounds in policy development concepts making policies much easier to understand and much more independant and modular. The reference policy is currently used in FC5 and RHEL5 and will be in Hardened Gentoo soon.
SLIDE (SELinux IDE) (http://selinux-ide.sf.net) is a policy IDE that works in conjunction with the reference policy. It makes writing policy easier now but the plans are for it to support much more wizard like writing in the future.
All of these tools work very well with SELinux as it is currently deployed by distributions, and with the hundreds of policies already written and available.
Hi, I am glad to see the news.
>Unfortunatly this app is not compatible with any of the widely used policies or deployments of SELinux.
Yes, it is correct.
We want to prepare understandable, configurable policy.
I am understanding reference policy and existing works are really great.
It is usable only for experts,
and suitable for military and government use,
but unusable for usual system administrator.
I still often hear users are disabling SELinux.
In some Japanese articles of Fedora Core,
writers recommend to disable SELinux!
I think alternative policy is also needed for Secure OS technology to be widely used.
# That’s also why Apparmor had appeared.
By seedit, we can use easy secure OS system
on SELinux platform that is installed in many distros.
#I also think if I have a time, I would like to our tool compatible with existing works..
>for example, remounting a drive at a different place totally changes the policy and the system can’t cope with it).
Yes, it is correct.
To be fair, I have to list up such “limitations”.
> It also removes large amounts of granularity that is potentially dangerous,
I have re-designed with university people,
but I have no published paper, it is a problem…
If you find some security concern, please tell me.
I will fix.
> for example, treating regular files and block devices the same.
It is fixed in 2.0 .
By default, domain can not touch devices except /dev directory.
I still often hear users are disabling SELinux.
In some Japanese articles of Fedora Core,
writers recommend to disable SELinux!
Hard to understand since the default enforced targeted policy works flawless as far as i can tell on FC5.
Seedit project is defenitely a start of something very usefull cool.Allthough it would be nice if sedit would “remember” the policies it already has filed.I have spend whole yesterday evening to make a custom policy for firefox www-browser.Seedit came over and over again with the same messages.(Can be my utter inexperienced naivity though 🙂
On the other hand, solutions being worked on like selinux policy modules (already in FC5, going into RHEL5) bring policy management much closer to useful and provide a framework for more management down the line.
Compared to earlier releases yes.But it’s still not as easy as AppArmor.Would be so nice if one could quickly ad some policies for whatever daemon,app,etc.Saves some precious time also.With Apparmor it’s one click on <update-profile>,start the app,<update-profile> until the app behaves to your liking.
I still like to use FC5 though,it has many more security features 🙂
The reference policy (http://serefpolicy.sf.net) has made leaps and bounds in policy development concepts making policies much easier to understand and much more independant and modular. The reference policy is currently used in FC5 and RHEL5 and will be in Hardened Gentoo soon.
I like the reference policy, but I don’t thing it is easy enough for the average system administrator. The default policies in both the RHEL4 en the reference policy in Fedora Core 5 work very well, but modifying a policy requires some studying to get to know SELinux. Many administrators (who are under enough pressure anyway) will just switch it off. AppArmor offers MAC that is easily configurable by anyone who knows how UNIX DAC works. SPDL offers something comparable for SELinux, and I think it is better to have that around than having people turn SELinux off.
Not everyone manages servers that handle banking transactions. E.g. for someone maintaining a Moodle server for high school students AppArmor or SELinux will provide enough protection on the MAC end, while it does take far less time to learn.
prevent someone from stealing your laptop with my personal data on it?
SELinux is a good example of what military historians call “preparing to fight the last war, again”.
Most developers who turn it off in FC5 do so because it gives too many false positives and too often gets in the way of getting work done.
How does this help me prevent someone from stealing your laptop with my personal data on it?
Don’t leave your laptop out of sight.
Most developers who turn it off in FC5 do so because it gives too many false positives and too often gets in the way of getting work done.
Trust me they know how to secure their stuff.Getting stuff done is sometimes a challenge enough even with SELinux off.On FC5 SELinux works pretty good (targeted at most attack prone vectors).Than again turning of SELinux is quite simple.
Edited 2006-07-08 20:04
How does this help me prevent someone from stealing your laptop with my personal data on it?
Don’t leave your laptop out of sight.
Read the sentence again.
Most developers who turn it off in FC5 do so because it gives too many false positives and too often gets in the way of getting work done.
Trust me they know how to secure their stuff.
Isn’t “trust me” contrary to the whole idea of SELinux?
[i]
Getting stuff done is sometimes a challenge enough even with SELinux off.On FC5 SELinux works pretty good (targeted at most attack prone vectors).Than again turning of SELinux is quite simple.
See first question of this post…
…this had been around when I made my Bell LaPadula based repository policy as part of my master thesis =)
How does this help me prevent someone from stealing your laptop with my personal data on it?
Easy answer, it doesn’t. That is not SELinux’s job to prevent someone from physically stealing yours or my laptop and accessing your private data by either cracking the password or booting into a livecd and accessing your data from there. As you well know, once someone has physical access, your data is most likely comprimised (encryption helps combat this). SELinux deals with a whole different set of problems and was never developed in order to guard your personal data from a physical theft of your laptop. Use filesystem encryption if you want to prevent some unauthorized person with physical access from comprimising your personal data.
SELinux is a good example of what military historians call “preparing to fight the last war, again”.
Please explain. Maybe its because you are just not knowledgable as to what SELinux purpose is, but you seem confused as to what SELinux does.
SELinux is a good example of what military historians call “preparing to fight the last war, again”.
Please explain. Maybe its because you are just not knowledgable as to what SELinux purpose is, but you seem confused as to what SELinux does.
SELinux is an attempt to apply mandatory access controls (MAC) to solve the orange book problem. It is not dissimilar from the work done on secure compartmented workstation (SCW) in the late ’80s and early ’90s. MAC was deemed unsuitable for modern security problems by the commercial security community in the mid ’90s [i]because of physical portability of computing equipment. This situation was exacerbated by the dramatically decreasing cost of computer resources. While MAC is suitable for point-of-contact terminals such as point-of-sales devices, where rigorous auditing is required, it is not sufficient by itself even in those applications.
The point of raising the laptop example was that the current issue in security is not maintaining security of data on a single system but rather securing the physical security of data on systems that fall into the hands of others. MAC is the Maginot Line of modern security, in the face of the blitzkreig of the swoop-and-grab laptop thief. I.E., it’s a brilliant way of solving last war’s problem.
MAC is really good at one thing: killing off an entire class of exploits – buffer overflows with right escalation as a result (the Type Enforcement part, when properly configugured, will make sure of that).
The policy used on Fedora systems targets a huge number of applications, notably servers, and adds another layer of security to them.
Hence, I’d say that MAC has its use today as well.
The policy used on Fedora systems targets a huge number of applications, notably servers, and adds another layer of security to them.
This is why we usually turn it off in FC systems. The ‘security’ it tends to add is mostly “gets in the way of legitimate users”.
On systems that are effectively one-user machines, running behind corporate firewalls, on unadvertised dhcped NATed networks, I’ll take the risk of remote exploits over the loss of functionality.
MACs are overkill and there are better ways to deal with buffer overflow exploits, anyway.
The policy used on Fedora systems targets a huge number of applications, notably servers, and adds another layer of security to them.
This is why we usually turn it off in FC systems. The ‘security’ it tends to add is mostly “gets in the way of legitimate users”.
According to:http://fedora.redhat.com/docs/selinux-faq-fc5/#id2906692
This is what is protected by the targeted policy:
(accton, amanda, httpd (apache), arpwatch, pam, automount, avahi, named, bluez, lilo, grub, canna, comsat, cpucontrol, cpuspeed, cups, cvs, cyrus, dbskkd, dbus, dhcpd, dictd, dmidecode, dovecot, fetchmail, fingerd, ftpd (vsftpd, proftpd, and muddleftpd), gpm, hald, hotplug, howl, innd, kerberos, ktalkd, openldap, auditd, syslog, logwatch, lpd, lvm, mailman, module-init-tools, mount, mysql, NetworkManager, NIS, nscd, ntp, pegasus, portmap, postfix, postgresql, pppd, pptp, privoxy, procmail, radiusd, radvd, rlogin, nfs, rsync, samba, saslauthd, snmpd, spamd, squid, stunnel, dhcpc, ifconfig, sysstat, tcp wrappers, telnetd, tftpd, updfstab, user management (passwd, useradd, etc.), crack, uucpd, vpnc, webalizer, xend, xfs, zebra )
All programs,deamons,services ,who can be nice attack vectors.Name a program that does get in the way of a regular user because of SELinux.And if so why don’t you help the devs to make even better policies?
MACs are overkill and there are better ways to deal with buffer overflow exploits, anyway.
That’s why a good secured system has multiple layers of defence.So All of the software in Fedora Core and Extras software repository is compiled using a security feature called fstack-protector.Besides that there’s FORTIFY_SOURCE security feature for gcc and glibc.
And you know what SELinux in its enforced targeted form doesn’t get in the way at all.
Edited 2006-07-09 20:28
Name a program that does get in the way of a regular user because of SELinux.
I don’t have a complete list, but FC5 with the default policy causes a bunch of used-to-work things to fail in weird ways with completely meaningless error messages.
Off the top of my head, I recall:
1) Developers not being able to use minicom because tty ports were inaccessable
2) Not being able to mount smb shares from the IT server because the user was no longer allowed the privilige.
3) Ditto NFS
4) not being able to tftp into a tftp server that had previously worked.
5) being denied access to a dhcpd that had previously provided access.
6) problems with udev
7) problems with usb device access
And if so why don’t you help the devs to make even better policies?
Because it’s been ten years since we figured out that MACs were a net loss due to problems like the above being far more common than the rare situation in which a MAC “saved the day”.
SELinux does more harm than good, and I’d rather see it die than more effort wasted on it.
SELinux does more harm than good, and I’d rather see it die than more effort wasted on it.
I don’t agree,as a matter of fact i just put an extra layer (Bastille) in place:-)