Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > +/* > + * There are not enough CAP bits available to make this > + * real, so Casey borrowed the capability that looks to > + * him like it has the best balance of similarity amd > + * low use. > + */ > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE Hey Casey, note that 64-bit capabilities are now in -mm, so you could grab your own capability. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote: > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > +/* > > + * There are not enough CAP bits available to make this > > + * real, so Casey borrowed the capability that looks to > > + * him like it has the best balance of similarity amd > > + * low use. > > + */ > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE > > Hey Casey, > > note that 64-bit capabilities are now in -mm, so you could grab your own > capability. Which brings up an interesting question - what to do with security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to Smack - other MAC modules like SELinux won't honor it. Maybe it should be CAP_SMACK_OVERRIDE. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote: > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > +/* > > > + * There are not enough CAP bits available to make this > > > + * real, so Casey borrowed the capability that looks to > > > + * him like it has the best balance of similarity amd > > > + * low use. > > > + */ > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE > > > > Hey Casey, > > > > note that 64-bit capabilities are now in -mm, so you could grab your own > > capability. > > Which brings up an interesting question - what to do with > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to > Smack - other MAC modules like SELinux won't honor it. Maybe it should > be CAP_SMACK_OVERRIDE. Yeah, I was thinking it would be renamed to something smack-specific. The concept of CAP_MAC_OVERRIDE is pretty general, but then users may for just that reason expect the capability to also let them override selinux and other capabilities. For instance the capabilities equivalent to a CAP_MAC_OVERRIDE would probably be CAP_SETPCAP, since it can be used to add capabilities back into your inheritable set. But we wouldn't want to share one capability for CAP_SETPCAP and CAP_SMACK_OVERRIDE. CAP_SETPCAP does let you regain CAP_SMACK_OVERRIDE, but a process could have CAP_SMACK_OVERRIDE but be denied CAP_NET_ADMIN for instance, or heck even CAP_DAC_OVERRIDE. So short answer is: I agree :) thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote: > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > +/* > > > + * There are not enough CAP bits available to make this > > > + * real, so Casey borrowed the capability that looks to > > > + * him like it has the best balance of similarity amd > > > + * low use. > > > + */ > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE > > > > Hey Casey, > > > > note that 64-bit capabilities are now in -mm, so you could grab your own > > capability. A proposal with merit. I'll do it. > Which brings up an interesting question - what to do with > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to > Smack - other MAC modules like SELinux won't honor it. Maybe it should > be CAP_SMACK_OVERRIDE. But what about the MAC modules like Smack that do honor it? They shouldn't be using a module specific capability, so calling it CAP_SMACK_OVERRIDE isn't right because then the SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE and bam, there go all your shiny new capability values. Further, Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the access control check, which is not the same thing at all at all. SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the restrictive model of the LSM. If someone ported the Trusted Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't have to allow read of higher labeled files, as the policy on that system never allowed that, even for privileged processes. SELinux has every right to make it's own choices regarding how it behaves relative to any specific capability because it is allowed to restrict access in any way it sees fit. I think that you would get in trouble if you changed the value of a capability on a task within the LSM, because that will impact the "usual" access checks, but I wouldn't expect to see you doing that. SELinux has gone in a different direction on privileged operations than capabilities, so it's not surprising that the two schemes don't look like they're meshing very well in this case. * SecureWare was an MLS "kit". The MLS version of HP/UX was based on it, and the Macintosh version got the first ever CMW evaluation. SELinux took many of the same design approaches as SecureWare, and in it's early versions bore a somewhat frightening resemblence to the earlier system. ** Trix4 allowed a privileged process to write lower labeled files, but not read higher labeled files. That way any files that got created "by accident" were assured to be labeled at least as high as the data they contained. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
--- Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote: > > --- Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote: > > > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > > > +/* > > > > > + * There are not enough CAP bits available to make this > > > > > + * real, so Casey borrowed the capability that looks to > > > > > + * him like it has the best balance of similarity amd > > > > > + * low use. > > > > > + */ > > > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE > > > > > > > > Hey Casey, > > > > > > > > note that 64-bit capabilities are now in -mm, so you could grab your > own > > > > capability. > > > > A proposal with merit. I'll do it. > > > > > Which brings up an interesting question - what to do with > > > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to > > > Smack - other MAC modules like SELinux won't honor it. Maybe it should > > > be CAP_SMACK_OVERRIDE. > > > > But what about the MAC modules like Smack that do honor it? > > They shouldn't be using a module specific capability, so > > calling it CAP_SMACK_OVERRIDE isn't right because then the > > SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE > > and bam, there go all your shiny new capability values. Further, > > Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the > > access control check, which is not the same thing at all at all. > > SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the > > restrictive model of the LSM. If someone ported the Trusted > > Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't > > have to allow read of higher labeled files, as the policy on that > > system never allowed that, even for privileged processes. > > Well, I'd be surprised to see that SecureWare port to Linux. As would I. We have seen the Addmax linux port, however, so don't expect me to bet a paycheck on SecureWare never coming in. > Or really any other label-based MAC implementations at all - how many > different ones does Linux need? It's no sweat off my nose if we have a dozen. SELinux and Smack are both general mechanisms. There are situations where very specific mechanisms would be useful, Smack would be overkill and SELinux massive overkill. Argue that those mechanisms would never make it upstream if you like, but I'm not convinced that they don't have a place. > Meanwhile, SELinux does implement MAC checks, and those checks do not > require an external privilege mechanism like capabilities and won't be > overridden by your shiny new capability. Which makes me uneasy about > calling it CAP_MAC_OVERRIDE. SELinux makes all sorts of checks, some of which fall into the traditional notion of MAC and others (e.g. port binding) that are not. SELinux has generally eschewed the capabilities paradigm in favor of enforcing the loaded "policy" and the rules it defines. > Explain it to a user - this capability is > for overriding MAC checks, except for SELinux. Or AppArmor or TOMOYO > or ... if you also count them as MAC (depending on your definition of > it). How do you explain the SELinux behavior to a user today? I have never figured out how to tell if running a given program against a given file will succeed or fail with SELinux. If couldn't be that much additional burden to explain. Put a comment in the reference policy that says: # # Policy not affected by CAP_MAC_OVERRIDE # > What the capability does is override the MAC checks in Smack. And since > you don't seem to need more than one such capability for Smack, calling > it CAP_SMACK_OVERRIDE makes sense to me. Yes, I understand that that makes some sense given your assumption that there won't be any more LSMs that would use it. But I want to be clear that the capability is not overriding the entire LSM, it is telling the LSM that the process has "appropriate privilege" and should act accordingly. An LSM that implements a descretionary mechanism would have the same opportunity to ignore CAP_DAC_OVERRIDE as SELinux would to ignore CAP_MAC_OVERRIDE. I think you might have a tough row to hoe if you're suggesting that CAP_DAC_OVERRIDE should be changed to CAP_MODEBIT_OVERRIDE. > > SELinux has every right to make it's own choices regarding how > > it behaves relative to any specific capability because it is > > allowed to restrict access in any way it sees fit. I think that > > you would get in trouble if you changed the value of a capability > > on a task within the LSM, because that will impact the "usual" > > access checks, but I wouldn't expect to see you doing that. > > Given that the capability module is implemented via LSM, the above makes > no sense - a LSM is free to tweak the capability bits or change what > capable() returns already. The fact that we don't presently do so is > another matter. Methinks there's a difference between what's possible and what's allowed here. It's possi
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
On Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote: > --- Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote: > > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > > +/* > > > > + * There are not enough CAP bits available to make this > > > > + * real, so Casey borrowed the capability that looks to > > > > + * him like it has the best balance of similarity amd > > > > + * low use. > > > > + */ > > > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE > > > > > > Hey Casey, > > > > > > note that 64-bit capabilities are now in -mm, so you could grab your own > > > capability. > > A proposal with merit. I'll do it. > > > Which brings up an interesting question - what to do with > > security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to > > Smack - other MAC modules like SELinux won't honor it. Maybe it should > > be CAP_SMACK_OVERRIDE. > > But what about the MAC modules like Smack that do honor it? > They shouldn't be using a module specific capability, so > calling it CAP_SMACK_OVERRIDE isn't right because then the > SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE > and bam, there go all your shiny new capability values. Further, > Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the > access control check, which is not the same thing at all at all. > SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the > restrictive model of the LSM. If someone ported the Trusted > Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't > have to allow read of higher labeled files, as the policy on that > system never allowed that, even for privileged processes. Well, I'd be surprised to see that SecureWare port to Linux. Or really any other label-based MAC implementations at all - how many different ones does Linux need? Meanwhile, SELinux does implement MAC checks, and those checks do not require an external privilege mechanism like capabilities and won't be overridden by your shiny new capability. Which makes me uneasy about calling it CAP_MAC_OVERRIDE. Explain it to a user - this capability is for overriding MAC checks, except for SELinux. Or AppArmor or TOMOYO or ... if you also count them as MAC (depending on your definition of it). What the capability does is override the MAC checks in Smack. And since you don't seem to need more than one such capability for Smack, calling it CAP_SMACK_OVERRIDE makes sense to me. > SELinux has every right to make it's own choices regarding how > it behaves relative to any specific capability because it is > allowed to restrict access in any way it sees fit. I think that > you would get in trouble if you changed the value of a capability > on a task within the LSM, because that will impact the "usual" > access checks, but I wouldn't expect to see you doing that. Given that the capability module is implemented via LSM, the above makes no sense - a LSM is free to tweak the capability bits or change what capable() returns already. The fact that we don't presently do so is another matter. > SELinux has gone in a different direction on privileged operations > than capabilities, so it's not surprising that the two schemes > don't look like they're meshing very well in this case. > > > * SecureWare was an MLS "kit". The MLS version of HP/UX was based >on it, and the Macintosh version got the first ever CMW evaluation. >SELinux took many of the same design approaches as SecureWare, >and in it's early versions bore a somewhat frightening resemblence >to the earlier system. > > ** Trix4 allowed a privileged process to write lower labeled files, >but not read higher labeled files. That way any files that got >created "by accident" were assured to be labeled at least as high >as the data they contained. > > > Casey Schaufler > [EMAIL PROTECTED] -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Schaufler wrote: > In the end we can call it CAP_LATE_FOR_DINNER if that's the only way > I can move forward. CAP_MAC_OVERRIDE is the obvious partner to > CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE > unnecessarily ties it to one LSM, and in spite of what some people > still seem to think, I see more LSMs in the pipeline. I'd personally not like to see SMACK appear in a capability name. No offense Casey, but SMACK may be displaced with YAMAC (*) someday, and I'd hate to have wasted a capability on it. Using CAP_MAC_OVERRIDE makes sense to me - even if its not (yet/ever) honored by all MAC LSMs. I do have a question about whether one capability is sufficient in general for MAC. Looking at the: http://wt.xpilot.org/publications/posix.1e/download.html last draft, there are no less than 5 capabilities (p173) allocated for MAC. Presumably there was a good reason for 5 and not 1 back then - could you summarize what is different now? Thanks Andrew (*) yet-another example of yet-another -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHR5mc+bHCR3gb8jsRAlB9AJsHPi1+fFp1ONKJCMFDpLS1lYG4AwCfYxMX 8aaU+sOBNHU01uldtrJ8cEI= =/USy -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe it was you who once eloquently observed that, at its heart, the POSIX (sic) capabilities model was all about providing a mechanism for overriding the prevailing security policy (be it MAC or DAC or whatever) in a defined way. Casey Schaufler wrote: > Now I know that there are lots of people who don't share my > views on granularity, but I have lots of experiance with this > and the cases where it actually makes sense to break the MAC > capabilities up are rare. > > That's my going in position, at any rate. I'm always open to > finding out why I'm wrong. Its not so much why you are wrong, as being clear that we're not using a generic name and inadvertently limiting ourselves to a SMACK-like model... It feels to me as if a MAC "override capability" is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... SELinux clearly feels no need for one, and browsing through your SMACK patch, there are many instances where this capability is used as an convenience privileged override. However, in other situations, it appears as if the capability is required for basic SMACK operations to succeed. My sense is that there is a case to be made for: CAP_MAC_ADMIN and CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or whatever MAC supports it) requires privilege to perform a privileged MAC operation, and the latter for saying "OK, I'm without a paddle but need one" (or words to that effect). Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHR8AA+bHCR3gb8jsRAqY/AJsGI56TDQyBD42LCovpJTYHkaL0pQCdHM5S kk5v2O4ohY2O0z93JNdKVBY= =dbQn -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Casey Schaufler wrote: > > In the end we can call it CAP_LATE_FOR_DINNER if that's the only way > > I can move forward. CAP_MAC_OVERRIDE is the obvious partner to > > CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE > > unnecessarily ties it to one LSM, and in spite of what some people > > still seem to think, I see more LSMs in the pipeline. > > I'd personally not like to see SMACK appear in a capability name. No > offense Casey, but SMACK may be displaced with YAMAC (*) someday, and > I'd hate to have wasted a capability on it. No offense taken. Technology continues marching forward and all that. > Using CAP_MAC_OVERRIDE makes > sense to me - even if its not (yet/ever) honored by all MAC LSMs. Thanks. > I do have a question about whether one capability is sufficient in > general for MAC. Looking at the: > > http://wt.xpilot.org/publications/posix.1e/download.html > > last draft, there are no less than 5 capabilities (p173) allocated for > MAC. Presumably there was a good reason for 5 and not 1 back then - > could you summarize what is different now? There are to my mind two important differences. The first is that my experiance with Trusted Irix (Trix from here on), which used (uses?) capabilities and MAC together, is that the granularity is lost on 99 44/100% of programs, programmers, evaluators, admins, and problems. You just don't get that many cases where it actually gets you anything to have less than all the MAC capabilities. Applications that care about MAC to the extent that they use the capabilities tend to use the lot, if not all the time, in certain circumstances. I'm afraid that I am not a major fan of fine grained privilege based on my experiance with it. The second and perhaps more important reason is that the POSIX draft assumed a Bell & LaPadula sensitivity model, or at least a model very much like it. What would CAP_MAC_DOWNGRADE mean on a Smack system configured: OneHand OtherHandr--- OtherHandGrippingHand r--- GrippingHand OneHand r--- What would CAP_MAC_UPGRADE mean, for that matter? It's even worse to consider that the relationships can change. CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ, and the other way around, and if you're not going to use one of the other capabilities after you find out interesting things using CAP_MAC_READ it's hard to figure why you'd bother. Now I know that there are lots of people who don't share my views on granularity, but I have lots of experiance with this and the cases where it actually makes sense to break the MAC capabilities up are rare. That's my going in position, at any rate. I'm always open to finding out why I'm wrong. Thank you. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Casey Schaufler wrote: > --- Andrew Morgan <[EMAIL PROTECTED]> wrote: >> I do have a question about whether one capability is sufficient in >> general for MAC. Looking at the: >> >> http://wt.xpilot.org/publications/posix.1e/download.html >> >> last draft, there are no less than 5 capabilities (p173) allocated for >> MAC. Presumably there was a good reason for 5 and not 1 back then - >> could you summarize what is different now? >> > There are to my mind two important differences. The first is that > my experiance with Trusted Irix (Trix from here on), which used (uses?) > capabilities and MAC together, is that the granularity is lost on > 99 44/100% of programs, programmers, evaluators, admins, and problems. > You just don't get that many cases where it actually gets you anything > to have less than all the MAC capabilities. Applications that care > about MAC to the extent that they use the capabilities tend to use the > lot, if not all the time, in certain circumstances. I'm afraid that > I am not a major fan of fine grained privilege based on my experiance > with it. > > The second and perhaps more important reason is that the POSIX > draft assumed a Bell & LaPadula sensitivity model, or at least > a model very much like it. What would CAP_MAC_DOWNGRADE mean on > a Smack system configured: > > OneHand OtherHandr--- > OtherHandGrippingHand r--- > GrippingHand OneHand r--- > Shout out to Niven & Pournelle :-) > What would CAP_MAC_UPGRADE mean, for that matter? It's even worse > to consider that the relationships can change. > > CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does > CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can > do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ, > and the other way around, and if you're not going to use one > of the other capabilities after you find out interesting things > using CAP_MAC_READ it's hard to figure why you'd bother. > All of that assumes a hierarchical security model (BLP, Biba). This depends on whether you think "MAC" means: * specifically the hierarchical models BLP and Biba, or * any policy system where the rules are mandatory with respect to the users The former would include SMACK, the venerable Argus Pitbull system (if it ever gets ported to LSM), and the recent MLS work implemented on top of FLASK. It would notably *not* include SELinux's Type Enforcement, AppArmor, or TOMOYO. If you take the latter view (a I do) then the meaning of MAC_READ vs. MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I have no clue WtF "relabel subject" means to AppArmor. But I can very easily understand what "CAP_MAC_OVERRIDE" means to AppArmor. So I'm with Casey; I support a simple 1-bit capability for MAC override. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Andrew Morgan wrote: > Its not so much why you are wrong, as being clear that we're not using a > generic name and inadvertently limiting ourselves to a SMACK-like model... > It seems we all agree that it is a bad idea to tie a POSIX Capability to one specific LSM model. > It feels to me as if a MAC "override capability" is, if true to its > name, extra to the MAC model; any MAC model that needs an 'override' to > function seems under-specified... An interesting observation. This is a core part of why I have always found the hierarchical models BLP and Biba to be unsatisfying. These systems essentially have one simple fixed policy "process label must dominate object label to get access", and then you express all the rest of your "policy" by labeling your stuff. It is impossible to manage such systems without a MAC_OVERRIDE escape hatch of some kind, because the "policy" is too simple and inflexible, e.g. it does not allow you to reclassify anything. > SELinux clearly feels no need for one, > That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than "process label must dominate object label". > and browsing through your SMACK patch, there are many instances where > this capability is used as an convenience privileged override. However, > in other situations, it appears as if the capability is required for > basic SMACK operations to succeed. > > My sense is that there is a case to be made for: CAP_MAC_ADMIN and > CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or > whatever MAC supports it) requires privilege to perform a privileged MAC > operation, and the latter for saying "OK, I'm without a paddle but need > one" (or words to that effect). > I don't get the difference. Both seem to permit the process to violate the MAC policy. I could make up a meaning for MAC_ADMIN that is different from MAC_OVERRIDE in the AppArmor sense, but I don't want to :-) and worse, I suspect the distinction would be different for each LSM. So let not, and just have one MAC_OVERRIDE capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
--- Crispin Cowan <[EMAIL PROTECTED]> wrote: > Andrew Morgan wrote: > > Its not so much why you are wrong, as being clear that we're not using a > > generic name and inadvertently limiting ourselves to a SMACK-like model... > > > It seems we all agree that it is a bad idea to tie a POSIX Capability to > one specific LSM model. I think that's fair. > > It feels to me as if a MAC "override capability" is, if true to its > > name, extra to the MAC model; any MAC model that needs an 'override' to > > function seems under-specified... That's the reason we have a privilege model, not just for MAC, but DAC as well. The Unix/Linux model where administration and system tasks are performed by normal processes that are just a little bit special, as opposed to a completely separate set of interfaces, often makes things look a little contrived. This is one of the advantages of SELinux, with it's model of complete specification. > An interesting observation. This is a core part of why I have always > found the hierarchical models BLP and Biba to be unsatisfying. These > systems essentially have one simple fixed policy "process label must > dominate object label to get access", and then you express all the rest > of your "policy" by labeling your stuff. It is impossible to manage such > systems without a MAC_OVERRIDE escape hatch of some kind, because the > "policy" is too simple and inflexible, e.g. it does not allow you to > reclassify anything. Wll... That's sort of what the "mandatory" is all about. > > SELinux clearly feels no need for one, > > > That's not quite right. More specifically, it already has one in the > form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" > permission. Its not that they don't need one, it is that they already > have one. They get to have one because they allow you to actually write > a policy that is more nuanced than "process label must dominate object > label". That SELinux doesn't require any capabilities is an artifact of design on that LSM. The whole notion of privilege is somewhat out of context when your model is to explicitly state how every possible decision ought to go. That is one important philosophical difference between SELinux and Smack, with Smack taking a higher level view on policy and hence privilege. > > and browsing through your SMACK patch, there are many instances where > > this capability is used as an convenience privileged override. However, > > in other situations, it appears as if the capability is required for > > basic SMACK operations to succeed. > > > > My sense is that there is a case to be made for: CAP_MAC_ADMIN and > > CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or > > whatever MAC supports it) requires privilege to perform a privileged MAC > > operation, and the latter for saying "OK, I'm without a paddle but need > > one" (or words to that effect). > > > I don't get the difference. Both seem to permit the process to violate > the MAC policy. I could make up a meaning for MAC_ADMIN that is > different from MAC_OVERRIDE in the AppArmor sense, but I don't want to > :-) and worse, I suspect the distinction would be different for each > LSM. So let not, and just have one MAC_OVERRIDE capability. I am pretty close to agreeing with Andrew that a distinction between allowing a process to change the state of the MAC configuration (e.g. set file or process MAC labels, add rules) and violating the rules is in order. SELinux can ignore both, AppArmor can ignore one, and the upcoming DG/UX port* can ask for further granularity when they show up. I will look in this direction and see if I can patches proposed before the virus in my sinuses knocks me out completely. Thank you. * DG/UX supported over 330 capabilities and is my personal poster child for excesses of granularity with regard to capabilities. I don't really expect to see a Linux port. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: Andrew Morgan wrote: It feels to me as if a MAC "override capability" is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... SELinux clearly feels no need for one, That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than "process label must dominate object label". Actually, a fully-secured strict-mode SELinux system will have no unconfined_t processes; none of my test systems have any. Generally "unconfined_t" is used for situations similar to what AppArmor was designed for, where the only "interesting" security is that of the daemon (which is properly labelled) and one or more of the users are unconfined. Even then "unconfined_t" is not an implicit part of the policy, it is explicitly given the ability to take any action on any object by rules in the policy, and it typically still falls under a few MLS labeling restrictions even in the targeted policy. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Kyle Moffett wrote: > On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: >> Andrew Morgan wrote: >>> It feels to me as if a MAC "override capability" is, if true to its >>> name, extra to the MAC model; any MAC model that needs an 'override' >>> to function seems under-specified... SELinux clearly feels no need >>> for one, >> That's not quite right. More specifically, it already has one in the >> form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" >> permission. Its not that they don't need one, it is that they already >> have one. They get to have one because they allow you to actually >> write a policy that is more nuanced than "process label must dominate >> object label". > Actually, a fully-secured strict-mode SELinux system will have no > unconfined_t processes; none of my test systems have any. Generally > "unconfined_t" is used for situations similar to what AppArmor was > designed for, where the only "interesting" security is that of the > daemon (which is properly labelled) and one or more of the users are > unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: * reboot to single user and hack away o hurts usability because you need physical presence to change policy, but is highly secure * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy o to me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want > Even then "unconfined_t" is not an implicit part of the policy, it is > explicitly given the ability to take any action on any object by rules > in the policy, and it typically still falls under a few MLS labeling > restrictions even in the targeted policy. Which is more or less the distinction I was trying to draw between hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor, etc.) that policy systems let you write yourself an escape hatch in policy, and MLS systems don't. Or at least they need to kludge something :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote: Kyle Moffett wrote: Actually, a fully-secured strict-mode SELinux system will have no unconfined_t processes; none of my test systems have any. Generally "unconfined_t" is used for situations similar to what AppArmor was designed for, where the only "interesting" security is that of the daemon (which is properly labelled) and one or more of the users are unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: [snip] * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy To me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want Well, in a strict SELinux system, someone who has been permitted the "Security Administrator" role (secadm_r) and who has logged in through a "login_t" process may modify and reload the policy. They are also permitted to view all files up to their clearance, write files below their level, and relabel files. On the other hand, they do not have any system-administration privileges (those are reserve for sysadm_r). Under the default policy the security administrator may disable SELinux completely, although that too can be adjusted as "load policy" is yet another specialized permission. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Kyle Moffett wrote: On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote: Kyle Moffett wrote: Actually, a fully-secured strict-mode SELinux system will have no unconfined_t processes; none of my test systems have any. Generally "unconfined_t" is used for situations similar to what AppArmor was designed for, where the only "interesting" security is that of the daemon (which is properly labelled) and one or more of the users are unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: [snip] * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy To me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want Well, in a strict SELinux system, someone who has been permitted the "Security Administrator" role (secadm_r) and who has logged in through a "login_t" process may modify and reload the policy. They are also permitted to view all files up to their clearance, write files below their level, and relabel files. On the other hand, they do not have any system-administration privileges (those are reserve for sysadm_r). Ofcourse secadm can give himself privileges to anything he wants, that isn't necessarily the point though, he is trusted to change the policy. He is, however, protected from other people: he can't, for example, read user_home_t files. This protects the integrity of his environment and the processes he runs. unconfined_t, of course, does not have this protection. Under the default policy the security administrator may disable SELinux completely, although that too can be adjusted as "load policy" is yet another specialized permission. load policy is pretty course grained, there are ways to make policy modification privileges more fine grained though such as by using the policy management server. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/