On Fri, 2005-05-06 at 08:04 -0400, Daniel J Walsh wrote:

Hein Coulier wrote:

...

hi, newby speaking here (totally lost in the selinux labyrinth).

What i want to accomplish with selinux is the following : i want to allow different end-users (with different roles) to do something with some files. I'll give you an example :

fileA : may be read by roleA and roleB fileB : may only be read by roleB ; audited fileC : may be read and changed by roleB ; audited

I read several pdf's, read the o'reilly book, but i seem to be unable to achieve my goal. Help would be appreciated.

You may want to look at ACLs and Auditing rather than SELinux.

ACLs are discretionary, so I don't think that will meet his need. Suggestion: 1) Convert your machine to strict policy (so that you have real user roles and domains), 2) Search the mailing list archives for discussions of how to add a new user role to the policy (e.g. see the full_user_role() macro and domains/user.te). Also, look at the recently added support for a separate security administrator role introduced by Dan.

On Fri, 2005-05-06 at 09:19 -0400, Daniel J Walsh wrote:

Yes I realize that but handling things like this with MAC is not that easy. Writing policy where different user roles have R, RW,RWX, No read is not a strong suit of MAC.

For specific data files, it should be relatively straightforward; he just needs to instantiate the roles via full_user_role(), define a few new file types for the particular data he wants to restrict, and add specific allow rules and auditallow rules between the new user domains and the new file types. I agree that a higher level language or tool would make life simpler, but the mechanism is certainly capable of supporting the need.

On Mon, 2005-05-09 at 13:29 +0200, Hein Coulier wrote:

thx for the feedback Stephen, but i'm still unable to succeed, i'm also getting some strange errors, so perhaps my installed policy isn't a good one to start with : # rpm -qa selinux-policy-targeted-sources

selinux-policy-targeted-sources-1.17.30-2.52.1

Yes, if you want to have user roles and domains, you need strict policy. targeted policy lacks the infrastructure for user roles and domains; it only knows about daemons.

# rpm -qa|grep -i release

redhat-release-4AS-2

Ah, unfortunately RHEL4 didn't ship with a strict policy included. You can take it up with your Red Hat support person, or grab the selinux-policy-strict* packages from Fedora Core (in the latter case, you will likely want to also upgrade your other SELinux-related packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, checkpolicy, policycoreutils, setools, setools-gui).

# define domains

type domainA_t, domain, file_type;

type domainB_t, domain, file_type;

type domainC_t, domain, file_type;

full_user_role() defines both a role and an initial domain for the role using the same prefix, so you don't need to separately define the domains here. Also, 'file_type' doesn't belong on domains. Domains are for processes, file types are for files.

allow domainA_t typeA_t:file r_file_perms;

auditallow domainB_t typeB_t:file r_file_perms;

auditallow domainC_t typeC_t:file rw_file_perms;

You would need allow rules as well for the latter domains; auditallow just says "audit when allowed", so you need both an allow rule and an auditallow rule in order to both allow the action and enable auditing of it when allowed.

# junk to tackle make-errors

This is because targeted policy lacks the infrastructure for user domains.

# create roles

full_user_role(roleA);

full_user_role(roleB);

role roleA_r types {domainA_t unconfined_t};

role roleB_r types {domainA_t domainB_t domainC_t unconfined_t};

full_user_role(X) should define a X_r role as well as a X_t domain as the initial domain for the role, and authorize the role for the domain. So you don't need to separately define domains and authorize the role for it. E.g. full_user_role(A) would create role A_r and type A_t, and authorize role A_r for A_t.

i also have a silly question, in a security context (eg user_u:object_r:typeA_t), what is the mening of user_u ?

It is a generic user identity used when the SELinux policy does not define a separate user identity for the Linux username. This is useful if you have a large number of users who do not need separation via SELinux, e.g. so you can map all unprivileged users to user_u and not need to maintain them in the policy individually.

On Mon, 09 May 2005 16:30:43 +0200, Hein Coulier said:

That is a bummer ! I read that redhat (even in rhel5) is not supporting the strict policy. Since we're running a lot of 3rd party products (oracle, websphere, openview, controlm, ...) , i doubt that managment will be willing to take the risk of running unsupported.

I'll have to address my supperiors, but i fear it might be over-and-out for selinux.

I remember seeing a statement on a RedHat page that their "lack of support" would basically mean "replicate your issue with enforcing=0 and then we'll talk", so things may not be as bad as all that...

On Mon, 09 May 2005 08:36:08 PDT, Erik Fichtner said:

And if they're not going to support it, they might as well not ship it in RHEL. Once you're running an unsupported configuration, one might as well do it for free. ;)

Umm.. *every* vendor does this. You post to linux-kernel with an oops that's tainted by the NVidia module, they'll ask you to replicate without that module loaded. I place a hardware support call to Dell, and they want to rule out any add-in PCI cards I've stuck in there myself. The IBM service manuals for an RS/6000 start with (basically) "gut the machine down to a minimum bootable config (ascii display, 4M memory, CD/ROM) and add stuff back till it breaks again".

The *important* part is that if I have a *NON*-Selinux problem, I can still get support. The only service call I had to make against RHEL3 was a botch in the aacraid drivers causing a panic on SMP when insmod'ed at system boot. Would have *royally* sucked if they had said "Won't support that config".

I don't see what the issue with RedHat saying "We won't answer questions if it looks like an SELinux policy that *you* installed is part of the problem".

Hein Coulier wrote:

...

Yes, if you want to have user roles and domains, you need strict policy. targeted policy lacks the infrastructure for user roles and domains; it only knows about daemons.

Ah, unfortunately RHEL4 didn't ship with a strict policy included. You can take it up with your Red Hat support person, or grab the selinux-policy-strict* packages from Fedora Core (in the latter case, you will likely want to also upgrade your other SELinux-related packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, checkpolicy, policycoreutils, setools, setools-gui).

That is a bummer ! I read that redhat (even in rhel5) is not supporting the strict policy. Since we're running a lot of 3rd party products (oracle, websphere, openview, controlm, ...) , i doubt that managment will be willing to take the risk of running unsupported.

I'll have to address my supperiors, but i fear it might be over-and-out for selinux.

Neverrtheless, thanks for the support and your time !

We are moving targeted policy to cover all non-userspace processes in the future, (RHEL5). I am not sure what you mean unsported. If you have layered products providing their own policy, that will be supported. The thing that is not supported, except through Professional Services, and picking an choosing which policy you will be running and modifying the existing targeted policy. If you modify existing policy so that it breaks the machine, Red Hat Support is going to have a difficult time diagnosing the problem. We just want to avoid that.

Quoting Hein Coulier hein.coulier@infoco.be:

Don't get me wrong : i understand why redhat shouldn't be eager to support strict policies. I also don't expect the problems to be generated by redhat, but by my 3rd party products : what if websphere (and our internet shop) stops running, or all our oracle databases in our 250 retail shops ? Even with support, damage in $ would be to big.

I hope that in a few years, linux will become like a mainframe with default security, and that it will be an evidence for all vendors that it's their duty to provide the neccessary rules to protect and keep their systems and data available.

I'm looking at this from a bit different angle. User can do lots of damage even if only "standard" Unix access controls are used (file permissions and ownerships). SELinux only brings this at more complex level. If it is too complex for Red Hat (or any other vendor) to support it at standard pricing levels, they could have "advanced security release" of product that includes strict policy with higher price tag (that would reflect higher support costs). Users of cheaper products should be allowed to install strict policy too, but if they need support, they'd need to switch back to targeted policy or upgrade to "advanced security" version of product. I see nothing wrong with such an approach.

Best solution for me would be that rbac on userbase could be made available in targeted policy.

I'm an total SELinux newbie (intend to improve on that), but yes, this would be nice to have feature if possible. In my work environmnt, we work with some sensitive data, and we must have audit trail whenever some types of files are touched (or we would fail external audits, which translates to lost jobs, simple as that). Problem with using Linux so far was lack of good auditing tools. SELinux looked promising on the surface, but if I can have auditing only with strict policy, and RHEL doesn't support it, than Red Hat has put itself out of game. If it was possible to create "targeted" per-user/group rules in targeted policy, with audit logging (when access is granted), that would be good enough.

I think you're all doing a great job, and i still believe selinux is the future. Keep up the good work.

I completely agree with this.

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

alex@milivojevic.org wrote:

Quoting Hein Coulier hein.coulier@infoco.be:

...

Don't get me wrong : i understand why redhat shouldn't be eager to support strict policies. I also don't expect the problems to be generated by redhat, but by my 3rd party products : what if websphere (and our internet shop) stops running, or all our oracle databases in our 250 retail shops ? Even with support, damage in $ would be to big.

I hope that in a few years, linux will become like a mainframe with default security, and that it will be an evidence for all vendors that it's their duty to provide the neccessary rules to protect and keep their systems and data available.

I'm looking at this from a bit different angle. User can do lots of damage even if only "standard" Unix access controls are used (file permissions and ownerships). SELinux only brings this at more complex level. If it is too complex for Red Hat (or any other vendor) to support it at standard pricing levels, they could have "advanced security release" of product that includes strict policy with higher price tag (that would reflect higher support costs). Users of cheaper products should be allowed to install strict policy too, but if they need support, they'd need to switch back to targeted policy or upgrade to "advanced security" version of product. I see nothing wrong with such an approach.

...

Best solution for me would be that rbac on userbase could be made available in targeted policy.

I'm an total SELinux newbie (intend to improve on that), but yes, this would be nice to have feature if possible. In my work environmnt, we work with some sensitive data, and we must have audit trail whenever some types of files are touched (or we would fail external audits, which translates to lost jobs, simple as that). Problem with using Linux so far was lack of good auditing tools. SELinux looked promising on the surface, but if I can have auditing only with strict policy, and RHEL doesn't support it, than Red Hat has put itself out of game. If it was possible to create "targeted" per-user/group rules in targeted policy, with audit logging (when access is granted), that would be good enough.

You can use the Audit Framework for watching certain files with or without SELinux.

Have you looked at auditd and auditctl.

...

I think you're all doing a great job, and i still believe selinux is the future. Keep up the good work.

I completely agree with this.

---

This message was sent using IMP, the Internet Messaging Program.

-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Mon, 09 May 2005 08:38:55 EDT, Stephen Smalley said:

On Mon, 2005-05-09 at 13:29 +0200, Hein Coulier wrote:

Ah, unfortunately RHEL4 didn't ship with a strict policy included. You can take it up with your Red Hat support person, or grab the selinux-policy-strict* packages from Fedora Core (in the latter case, you will likely want to also upgrade your other SELinux-related packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, checkpolicy, policycoreutils, setools, setools-gui).

Modulo the support issues, there any known gotchas of running a basically RHEL4 box with the userspace pieces from FC4 (missing kernel support, etc), or is it something that will pretty much work? (And yes, I know that getting things working like Apache serving up PHP scripts that call mysql are *my* problem - I'm more worried about things sneaking up and biting me on the tookus while I'm busy trying to get that stuff working...)