On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
> 2007/5/27, Kyle Moffett <mrmacman_g4@xxxxxxx>:
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*:
>> 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.
> 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:
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).
> 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
> 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.
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
Attachment:
fig.png
Description: PNG image