On Tue, 1 Oct 2002, Tom wrote:

> I built a fresh kernel from 2.4.19-lsm1 sources today, so the kernel
> should actually be newer than the checkpolicy program (actually,
> they're both from the August release).

Not if you are using policy version 12. That change didn't occur until the aforementioned patch that I posted, when the access vector definitions changed. If that patch was merged into the Debian selinux packages, then you should have a new kernel that uses policy version 12. If you are building the old kernel sources from the release but trying to use a newer checkpolicy+policy, then you naturally have a problem.

> I'm not sure what to think about the actual behaviour of the system,
> though. I believe it is misbehaving and not failing safely - even
> though it can't load the policy, it boots up and lets me log in (into
> an unlabeled context). However, even though I'm running in permissive
> mode, I get "permission denied" on most file access attempts (including
> something as simple as "ls"). IMHO, when it can't load the policy, it
> should either panic (enforcing mode) or start up with a "allow all"
> default (permissive mode). Feel free to correct me on this, it's just
> what I would have expected.

If you build your kernel without the development module option (i.e. always in enforcing mode, no way to switch into permissive mode), then it will panic if it cannot load a policy after mounting the root filesystem. If you build your kernel with the development module option, then it only issues a warning if it cannot load a policy and SELinux is effectively off until you either explicitly load a policy via load_policy or you try to toggle into enforcing mode via avc_toggle. I suppose that we could change the latter case so that if you boot with enforcing=1, then it will also panic if no policy is present. I don't see the behavior that you describe when booting without a valid policy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
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.