From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46B24701.1090108@manicmethod.com> Date: Thu, 02 Aug 2007 17:05:05 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Stephen Smalley CC: Paul Moore , Eric Paris , selinux@tycho.nsa.gov, jmorris@namei.org, Karl MacMillan Subject: Re: [PATCH] kernel: selinux: policy selectable handling of unknown classes and perms References: <1185983352.3673.16.camel@localhost.localdomain> <1186068805.2434.40.camel@moss-spartans.epoch.ncsc.mil> <1186075512.4405.34.camel@localhost.localdomain> <200708021443.26314.paul.moore@hp.com> <46B23421.1030101@manicmethod.com> <1186085189.2434.178.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1186085189.2434.178.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Thu, 2007-08-02 at 15:44 -0400, Joshua Brindle wrote: > >> Paul Moore wrote: >> >>> On Thursday, August 2 2007 1:25:12 pm Eric Paris wrote: >>> >>> >>>> Maybe instead a versioning scheme? Every security check comes with a >>>> 'version.' Every time we add/change a security check we add one to the >>>> 'version' for that check. If the policy handed to the kernel has a >>>> 'version' less than the value we get from the security hook call coded >>>> in kernel we can just allow it? Maybe that could be a solution to the >>>> issue I am addressing now along with things like this netlabel change? >>>> It certainly would have to touch a whole lot of stuff and might be a >>>> pain to keep up with. Lets say I move a security hook around in a >>>> function, I need to decide if the version need to be bumped on that hook >>>> or not. Not impossible, but not pretty. Also probably means a policy >>>> version update, which in turn breaks the discussion which we have >>>> ongoing above.... >>>> >>>> >>> While I'm not an expert on the policy aspects of this discussion and how the >>> kernel and userspace objects managers interact I think at some point we are >>> going to need something like what Eric proposes above. With the requirement >>> that new kernels must not regress when using old policy we are going to run >>> into issues as we move forward and add new permission checks. While I don't >>> think we've seen it yet, it is reasonable to think that this problem will >>> expand into userspace as we develop more and more userspace object managers >>> such a X, CUPS, Postgres, etc. >>> >>> I know the changes aren't likely to be pretty, I'm kinda cringing at the >>> thought actually, but I think it's a necessary evil for the long term >>> survivability of SELinux. At least that's what I took away from Eric and >>> Stephen's comments on this thread and I tend to agree. >>> >>> >> I'd have to give a pretty hard NAK (for what it would be worth) to the >> versioning system, it simply doesn't scale; in the past we've used >> policy versions to decide how some permission checks work (see fine >> grained netlink discussions) and it was fairly non-ideal. >> > > Well, that was "policy format version" vs. a separate version that > identifies the set of security checks known to / expected by the policy. > Or, as I said in my other email, a bitmap of check indices, where each > check (not permission, but individual check) has its own unique index > assigned when it is first introduced and never recycled. > > I was just giving an example on my the policy versioning idea doesn't scale, I know it would be something separate from policy format version but that doesn't necessarily make it better. >> I have to go >> back to the 'the object manager should decide how to deal with unknown >> permissions' argument. The object manager knows how its objects are >> used, and how the security system affects those objects, it is in the >> best position to make those decisions, the security server can only make >> a rough estimation on what the object manager and user want to do, which >> may or may not be accurate. >> > > It's actually a policy issue - what set of checks are required in order > to meet a given policy. > > Yes, I was agreeing with that before but when it comes down to it the object manager is always responsible for enforcing said policy, and it can always make the decision not to. If the object manager decides a lack of security policy means that something should be denied wouldn't it know better than a security server with no concept of the object classes? >> Here is an example, granted kernexec uses the reboot capability but >> suppose we wanted to make it a separate permission, I'm fairly certain >> that we'd want to always deny it if the policy didn't know about it, >> > > Actually, I'm sure Fedora would want to allow it by default if it wasn't > yet defined. > > I'd certainly hope not but that probably isn't the issue. >> whereas SE-X is completely unusable without policy and still has OS >> level policy determining who can talk to the X daemon itself, SE-X would >> have to make a determination of whether to run at all or run with course >> grained permissions, chances are most people would want the latter. >> > > That's a policy issue ;) > > Its also an object manager issue, as explained above. >> This >> means we'd actually have environments where some object managers deny by >> default and others allow (or even short circuit access attempts >> altogether). This is ideal from a scalability and dynamic system >> perspective and seems by far to be the best solution. >> > > -- 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.