I spent my first couple of days in SELinux tinkering with FC2, and only installed FC3 today. It's possible I may not yet fully appreciate the differences in working with the targeted policy. I see now that even though multiple roles are defined, they're all assigned to the unconfined_t domain.
The targeted policy appeals to me for the obvious reasons: I'd like most of the system to run without the complications introduced by SELinux. I'd rather not go back to the strict policy unless I have to.
My goal, however, is to do some fairly serious policy writing to lock down a few applications, but leave most of the system alone. I think I'll need to make new domains, new roles, and new transitions to do this.
From my limited understanding, it looks like even though the default
targeted policy is role-blind, I should be able to modify it to add my own custom roles that aren't of type unconfined_t. After all, it's still SELinux under the hood, isn't it? Or am I missing something fundamental? Will I have no choice but to use the strict policy as my starting point?
- Steve
-----Original Message----- From: Stephen Smalley [mailto:sds@epoch.ncsc.mil] Sent: Thursday, January 13, 2005 4:51 PM To: Fedora SELinux support list for users & developers. Subject: Re: Creating new roles
On Thu, 2005-01-13 at 16:47, Steve Brueckner wrote:
I'm just getting started with SELinux. I've read a bunch and just
installed
FC3.
I'm trying to add a new role, but can't figure out where roles are
defined.
The O'Reilly book says they're "scattered around the policy tree" and
Debian
references say they're in users.te, which doesn't appear to exist in FC3.
If I can find where the few extant roles are defined, I can probably
figure
out how to define my own. Or should I be trying to do it from scratch by making a new file? In which case I could use some hints on how to do it.
By default, FC3 uses the "targeted" policy, which only confines specific network services and does not have any real notion of user roles and domains. You can switch to the "strict" policy by installing it (e.g. yum install selinux-policy-strict*) and then using system-config-securitylevel GUI to set the active policy to it and rebooting, at which point it should automatically relabel. Or manually, you can just edit /etc/selinux/config to set the SELINUXTYPE to strict, reboot single user, and run fixfiles relabel by hand, then bring the system up the rest of the way. Have you read the Fedora SELinux FAQ? http://fedora.redhat.com/docs/selinux-faq-fc3/
On Thu, 2005-01-13 at 17:47, Steve Brueckner wrote:
I spent my first couple of days in SELinux tinkering with FC2, and only installed FC3 today. It's possible I may not yet fully appreciate the differences in working with the targeted policy. I see now that even though multiple roles are defined, they're all assigned to the unconfined_t domain.
The targeted policy appeals to me for the obvious reasons: I'd like most of the system to run without the complications introduced by SELinux. I'd rather not go back to the strict policy unless I have to.
My goal, however, is to do some fairly serious policy writing to lock down a few applications, but leave most of the system alone. I think I'll need to make new domains, new roles, and new transitions to do this.
From my limited understanding, it looks like even though the default
targeted policy is role-blind, I should be able to modify it to add my own custom roles that aren't of type unconfined_t. After all, it's still SELinux under the hood, isn't it? Or am I missing something fundamental? Will I have no choice but to use the strict policy as my starting point?
The mechanism is the same, only the policy configuration differs. But the differences in the policy configurations are substantial and structural, and it should be easier to take the strict policy as your starting point and move certain programs into its unconfined_t domain if you truly want user roles and domains. But if you merely want to lock down additional applications, you can do that with the targeted policy, and you do not need new roles at all, just domains for those programs. The process transition permission controls the ability to transition among domains on a pairwise basis, so the fact that domains foo, bar, and baz are all associated with role R does not mean that they can jump among each other.
selinux@lists.fedoraproject.org