Message-ID: <9d732d950705280341x78575d85kaf95b0e2884723f3@mail.gmail.com>
Date:	Mon, 28 May 2007 19:41:11 +0900
From:	"Toshiharu Harada" <haradats@...il.com>
To:	"Kyle Moffett" <mrmacman_g4@....com>
Cc:	"James Morris" <jmorris@...ei.org>, casey@...aufler-ca.com,
	"Andreas Gruenbacher" <agruen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007/5/27, Kyle Moffett <mrmacman_g4@....com>:
> On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
> > 2007/5/27, Kyle Moffett <mrmacman_g4@....com>:

> How is that argument not trivially circular?  "Foo has an assumption
> that foo-property is always properly defined and maintained."  That
> could be said about *anything*:

What I wanted to mention was the difficulties or efforts to make
assumptions real.  I never meant a circular argument, but if you
felt so I apologize sincerely.

> >> If you can't properly manage your labels, then how do you expect
> >> any security at all?
> >
> > Please read my message again. I didn't say, "This can never be
> > achieved".  I said, "This can not be easily achieved".
>
> So you said "(data labels) can not be easily achieved".  My question
> for you is: How do you manage secure UNIX systems without standard
> UNIX permission bits?  Also:  If you have problems with data labels
> then what makes pathname based labels "easier"?  If there is
> something that could be done to improve SELinux and make it more
> readily configurable then it should probably be done.

Permission bits can be checked easily with "ls" command,
but assuring the correctness of labels are not that easy.
I'll try to explain.

The correctness of the permission bit for a given file can be judged
solely by the result of "ls" command.  The correctness of the label,
on the other hand, can't be judged without understanding of whole policy
including domain transitions. (see the attached figure)
I can imagine that once one get the complete SELinux policy,
then it is able to modify and maintain it.

I don't say making a complete SELinux policy is impossible,
and actually you said you did it.  But to be frank, I don't think
you are the average level user at all. ;-)

> > I'm very interested in how you can know that you have the correct
> > object labeling (this is my point). Could you tell?
>
> I know that I have the correct object labeling because:

Do you mind if I add this?

0) I understood the default policy and perfectly understand the
every behavior of my system.

this is where the difficulties exist.

>   1) I rewrote/modified the default policy to be extremely strict on
> the system where I wanted the extra security and hassle.
>   2) I ensured that the type transitions were in place for almost
> everything that needed to be done to administer the system.
>   3) I wrote a file-contexts file and relabeled *once*
>   4) I loaded the customized policy plus policy for restorecon and
> relabeled for the last time
>   5) I reloaded the customized policy without restorecon privileges
> and without the ability to reload the policy again.
>   6) I never reboot the system without enforcing mode.
>   7) If there are unexpected errors or files have incorrect labels,
> I have to get the security auditor to log in on the affected system
> and relabel the problematic files manually (rare occurrence which
> requires excessive amounts of paperwork).

Thank you for the procedures.  It's quite helpful.

> > I don't deny DAC at all.  If we deny DAC, we can't live with Linux
> > it's the base.  MAC can be used to cover the shortages of DAC and
> > Linux's simple user model, that's it.
> >
> > From security point of view, simplicity is always the virtue and
> > the way to go.  Inode combined label is guaranteed to be a single
> > at any point time.  This is the most noticeable advantage of label-
> > based security.
>
> I would argue that pathname-based security breaks the "simplicity is
> the best virtue (of a security system)" paradigm, because it
> attributes multiple potentially-conflicting labels to the same piece

Every pathname-based security must provide the mechanism
to prevent a conflicting/malicious access, otherwise it's junk.

I have a question for you.  With current implementation of
SELinux, only one label can be assigned.  But there are cases
that one object can be used in different context, so I think
it might help if SELinux would allow objects to have
multiple labels. (I'm not talking about conflicts here)
What do you think?

> > But writing policy with labels are somewhat indirect way (I mean,
> > we need "ls -Z" or "ps -Z").  Indirect way can cause flaw so we
> > need a lot of work that is what I wanted to tell.
>
> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I
> do that only when I actually think I mislabeled files.

I believe what you wrote, but it may not be as easy for average Linux users.

> Typically the SELinux-policy-development cycle is:
>   1)  Modify and reload the policy
>   2)  Relabel the affected files (either by hand or with some
> automated tool like restorecon)
>   3)  Rerun the problem program or daemon
>   4)  Examine the errors in the audit logs.  If there are no errors
> and it works then you're finished.
>   5)  Go back to step 1 and fix your policy

Cheers,
Toshiharu Harada

Download attachment "fig.png" of type "image/png" (15431 bytes)

Powered by blists - more mailing lists