On Wed, 2004-09-15 at 22:43 -0400, Ivan Gyurdiev wrote:

> What you have right now is not least privilege possible.
> This is the point where my computer is broken and does not work.

You need to point out specific things that are broken.

> > Normal users don't just randomly cat files in /etc.
>
> So what exactly is the definition of a SElinux MAC system?
> Is it a system which allows only what "normal users do",
> and how exactly do you figure out what that is?

There are no hard and fast rules, but I am quite sure that no one's end goal is "cat random file in /etc". Instead, you cat a file to achieve something else. That something else is what is interesting.

> If there is a general consensus that a user has no job
> reading a particular file in /etc, why is it still created/installed as
> world readable.

One reason is because (at least before ACLs) it's complicated to restrict access to only mildly sensitive files that are shared across multiple daemon uids that a user doesn't really need read access to.

> Why don't you implement the MAC at the permissions level
> and make SElinux respect that?

That doesn't make any sense, if the MAC system respected DAC permissions it wouldn't be MAC.

> So if a case can be made you'll change the SElinux context to respect
> the Unix permissions?

No. What we were discussing here is for a user to read a particular file in /etc. Even if the file is world readable, that doesn't mean that access to it would be granted for all SELinux domains. Someone may deliberately create a domain that has no access to etc_t. A good reason to do this would be for a secured chroot setup.

What we would do is grant user_t and staff_t permissions for the file.

> If a case can't be made, why don't you change the
> Unix permissions (in the rpm or whatever creates the file) instead of
> adding restrictions on the SELinux level?

Because it may be very annoying to do some of this using Unix permissions, and generally not worth the trouble.

> If I added the permissions
> manually, doesn't that indicate I definitely want to be able to read the
> file? Seems to me like "usercanread" and rwx bits provide duplicate
> functionality, and furthermore contradict each other.

No, not at all. To make this discussion a bit more concrete, suppose that in the strict policy your sendmail daemon (which runs as root) is compromised. The compromised daemon can set all the bits on files in /etc it wants with just Unix permissions. But with SELinux, even if it had permission to make /etc/shadow a+r, other domains wouldn't have access to it.

SELinux and Unix permissions are quite separate for good reason.

> Look, I don't really know how to use SELinux. I have a general idea
> of how it works, and I've looked at the policy files.
> I don't want to drop files anywhere when there's already a mechanism
> that deals with whether I can read or write files - Unix permissions.

What you really seem to be saying is that your system doesn't need mandatory access control for users. If so, use the targeted policy, which leaves users in unconfined_t, with no SELinux restrictions applied.

> You can claim that because I don't know how to use SELinux

I would never said that.. Heck, I'm still learning how to use SELinux best myself and I've been at it for over a year now.

> I shouldn't
> be using it and override Unix permissions for my own good... or you
> can make this process transparent for me and respect existing
> mechanisms.
>
> Why can't the strict policy be transparent for the end user ?

I think you just want the targeted policy.

> Do you not see value in that? Is the restriction imposed on what user_t
> can do the defining feature of the strict policy?

No, but it is a very core feature.

> I wanted to use strict
> policy because it's more comprehensive (more contexts - more
> separation),

Do you have a particular daemon you feel should be in the strict policy?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.



application/pgp-signature attachment: This is a digitally signed message part