Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > ... > > As for the script, I'm partway through debugging it but my time is > all chewed up with other stuff now, so it may take me an extra couple > days. Any progress on this? 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: ... As for the script, I'm partway through debugging it but my time is all chewed up with other stuff now, so it may take me an extra couple days. Any progress on this? 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 22 2007 11:47, Casey Schaufler wrote:
>> As we have to maintain selinux, anyway, I don't see why simplification
>> layer is a problem.
>
>It's an issue if you want to do simple things, have the resources to
>do simple things, but go over budget because the simple things are
>built on top of complex things that you don't need. I see this crop
>up frequently with IT infrastructures, where simple problems get
>solved using completely unnecessary components just because those
>components are available.
class LinkedList {} for example. Just look how simple the linux
kernel does it ;-)
Jan
--
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 22 2007 11:47, Casey Schaufler wrote:
As we have to maintain selinux, anyway, I don't see why simplification
layer is a problem.
It's an issue if you want to do simple things, have the resources to
do simple things, but go over budget because the simple things are
built on top of complex things that you don't need. I see this crop
up frequently with IT infrastructures, where simple problems get
solved using completely unnecessary components just because those
components are available.
class LinkedList {} for example. Just look how simple the linux
kernel does it ;-)
Jan
--
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > but you written it in wrong language. You > > > written it in C, while you should have written it in SELinux policy > > > language (and your favourite scripting language as frontend). > > > > I have often marvelled at the notion of a simplification layer. > > I believe that you build complex things on top of simple things, > > not the other way around. > > As we have to maintain selinux, anyway, I don't see why simplification > layer is a problem. It's an issue if you want to do simple things, have the resources to do simple things, but go over budget because the simple things are built on top of complex things that you don't need. I see this crop up frequently with IT infrastructures, where simple problems get solved using completely unnecessary components just because those components are available. If you want to maintain an SELinux policy that looks like it does smackish things in addition to the reference policy that's OK by me. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
> > but you written it in wrong language. You > > written it in C, while you should have written it in SELinux policy > > language (and your favourite scripting language as frontend). > > I have often marvelled at the notion of a simplification layer. > I believe that you build complex things on top of simple things, > not the other way around. As we have to maintain selinux, anyway, I don't see why simplification layer is a problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. As we have to maintain selinux, anyway, I don't see why simplification layer is a problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek [EMAIL PROTECTED] wrote: but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. As we have to maintain selinux, anyway, I don't see why simplification layer is a problem. It's an issue if you want to do simple things, have the resources to do simple things, but go over budget because the simple things are built on top of complex things that you don't need. I see this crop up frequently with IT infrastructures, where simple problems get solved using completely unnecessary components just because those components are available. If you want to maintain an SELinux policy that looks like it does smackish things in addition to the reference policy that's OK by me. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote: > > --- Kyle Moffett <[EMAIL PROTECTED]> wrote: > >> Well, in this case the "box" I want to secure will eventually be > >> running multi-user X on a multi-level-with-IPsec network. For > >> that kind of protection profile, there is presently no substitute > >> for SELinux with some X11 patches. AppArmor certainly doesn't > >> meet the confidentiality requirements (no data labelling), and > >> SMACK has no way of doing the very tight per-syscall security > >> requirements we have to meet. > > > > And what requirements would those be? Seriously, I've done Common > > Criteria and TCSEC evaluations on systems with less flexibility and > > granularity than Smack that included X, NFSv3, NIS, clusters, and > > all sorts of spiffy stuff. > > These are requirements more of the "give the client warm fuzzies". OK, that's perfectly reasonable. If the client has been sold on the concept of SELinux the client will get warm fuzzies only from SELinux. Security is how you feel about it, after all. > On the other hand, when designing a box that could theoretically be > run on a semi-public unclassified network and yet still be safe > enough to run classified data over IPsec links, you want to give the > client all the warm fuzzies they ask for and more. Yes. Of course, a little hard technology behind it doesn't hurt, either. > > I mean, if the requirement is anything short of "runs SELinux" I > > have good reason to believe that a Smack based system is up to it. > > "up to it", yes, but I think you'll find that beyond the simplest > policies, an SELinux policy that properly uses the SELinux > infrastructure will be much shorter than the equivalent SMACK policy, Well, I find that hard to believe. Maybe I'm only thinking of what you would consider the simplest policies. > not even including all the things that SELinux does and SMACK doesn't. Of course. > >> I didn't make this clear initially but that is the kind of system > >> I'm talking about wanting to secure some 50 million lines of code on. > > > > Cool. SELinux provides one approach to dealing with that, and the > > huge multiuser general purpose machine chuck full of legacy > > software hits the SELinux sweet spot. > > Well, given that 99.9% of the systems people are really concerned > about security on are multi-user general-purpose machines chuck full > of legacy software, that seems to work just fine. Err, no. By unit count such systems are extremely rare. There is tremendous concern for security in your cell phone, your DVR, your PDA, and even your toaster. > If it's a single- > user box then you don't even need MAC, just a firewall, a good locked > rack/case/keyboard/etc, and decent physical security. You cell phone has really lousy physical security. > If it's > entirely custom-controlled software then you can just implement the > "MAC" entirely in your own software. "General-purpose" vs "special- > purpose" is debatable, so I'll just leave that one lie. Indeed. Total control over the software on your phone is not a competetive option for a provider. > Replying to another email: > >> but you written it in wrong language. You written it in C, while > >> you should have written it in SELinux policy language (and your > >> favourite scripting language as frontend). > > > > I have often marvelled at the notion of a simplification layer. I > > believe that you build complex things on top of simple things, not > > the other way around. > > There is no "one answer" to this question in software development. You're correct. Can I quote you on that? > Generally you prioritize things based on maximizing maintainability > and speed and minimizing code, bugs, and complexity. Those are often > both conflicting and in agreement. Here are a few common examples of > simple-thing-on-complex-thing: > ... > > Look at the SELinux model again; it has the following things: >(A) Labels on almost-all user-visible kernel objects >(B) Individual access rules for almost every operation on those > objects >(C) "Transition" rules to set the label on newly created objects. >(D) Fundamental "constraints" which enforce hard limits on what > may be permitted with "allow" rules > > From a fundamental standpoint it's harder to get much simpler than > that. It's easy to get simpler than that: (A) Labels on all objects and subjects (B) Access rules for subjects and objects No transformations. Operations in terms of rwx. lots simpler. > On top of that model, we also have a bit of additional > *flexibility* for MLS/RBAC, although that flexibility may be ignored > completely. >(1) You can define "users" which may only assume some "roles" >(2) You can define "roles" may only run in some "types" >(3) There's a simple way of declaring multiple "levels" and
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: Well, in this case the "box" I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff. These are requirements more of the "give the client warm fuzzies". On the other hand, when designing a box that could theoretically be run on a semi-public unclassified network and yet still be safe enough to run classified data over IPsec links, you want to give the client all the warm fuzzies they ask for and more. I mean, if the requirement is anything short of "runs SELinux" I have good reason to believe that a Smack based system is up to it. "up to it", yes, but I think you'll find that beyond the simplest policies, an SELinux policy that properly uses the SELinux infrastructure will be much shorter than the equivalent SMACK policy, not even including all the things that SELinux does and SMACK doesn't. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot. Well, given that 99.9% of the systems people are really concerned about security on are multi-user general-purpose machines chuck full of legacy software, that seems to work just fine. If it's a single- user box then you don't even need MAC, just a firewall, a good locked rack/case/keyboard/etc, and decent physical security. If it's entirely custom-controlled software then you can just implement the "MAC" entirely in your own software. "General-purpose" vs "special- purpose" is debatable, so I'll just leave that one lie. Replying to another email: but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. There is no "one answer" to this question in software development. Generally you prioritize things based on maximizing maintainability and speed and minimizing code, bugs, and complexity. Those are often both conflicting and in agreement. Here are a few common examples of simple-thing-on-complex-thing: * pthreads on top of clone() * open(some_string) on top of all the complex VFS machinery * "netcat" on top of the vast Linux network stack including support for arbitrary packet filtering and transformation. In addition, "simple" is undesirable if it makes the implementation less generic for no good reason. Would you want to use the "simple" MS Windows disk-drive model under Linux? Every disk is its own letter and has its files under it. Oh, you wanted to mount a filesystem over C:\tmp? Sorry, we don't support that, too bad. Under Linux we have a very flexible and powerful VFS which lets you do very crazy things, and then for the user's convenience we have various "simple" interfaces (like Gnome/KDE/XFCE). Software development is very much about finding the Right Model(TM) to underlie the system, and then building any simplifications-to-the- user on top of the very simple model. Look at the SELinux model again; it has the following things: (A) Labels on almost-all user-visible kernel objects (B) Individual access rules for almost every operation on those objects (C) "Transition" rules to set the label on newly created objects. (D) Fundamental "constraints" which enforce hard limits on what may be permitted with "allow" rules From a fundamental standpoint it's harder to get much simpler than that. On top of that model, we also have a bit of additional *flexibility* for MLS/RBAC, although that flexibility may be ignored completely. (1) You can define "users" which may only assume some "roles" (2) You can define "roles" may only run in some "types" (3) There's a simple way of declaring multiple "levels" and "dominance". So you see, SELinux is a pretty fundamental description of the degrees of flexibility needed to secure everything. That kind of FUNDAMENTAL description is what belongs in the kernel. Anything else can and should be built on top with
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote: > > On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: > >> If you can show me a security system other than SELinux which is > >> sufficiently flexible to secure those 2 million lines of code > >> along with the other 50 million lines of code found in various > >> pieces of software on my Debian box then I'll go put on my dunce > >> hat and sit in the corner. > > > > /me hands Kyle a dunce cap. :) > > > > Unfortunately, I have to agree that both AppArmor and Smack have at > > least the potential of qualifying as "securing the 2M lines of code". > > > > The part that Kyle forgot was what most evals these days call the > > "protection profile" - What's the threat model, who are you > > defending against, and just how good a job does it have to do? > > I'll posit that for a computer that is (a) not networked, (b) > > doesn't process sensitive information, and (c) has reasonable > > physical security, a security policy of "return(permitted);" for > > everything may be quite sufficient. > > Well, in this case the "box" I want to secure will eventually be > running multi-user X on a multi-level-with-IPsec network. For that > kind of protection profile, there is presently no substitute for > SELinux with some X11 patches. AppArmor certainly doesn't meet the > confidentiality requirements (no data labelling), and SMACK has no > way of doing the very tight per-syscall security requirements we have > to meet. And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff. I mean, if the requirement is anything short of "runs SELinux" I have good reason to believe that a Smack based system is up to it. > I didn't make this clear initially but that is the kind of > system I'm talking about wanting to secure some 50 million lines of > code on. Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot. > > (Of course, I also have boxes where "the SELinux reference policy > > with all the MCS extensions plus all the LSPP work" is someplace > > I'm trying to get to). > > Well, for some of the systems we distribute, "all the MCS extensions > plus all the LSPP work" is nowhere near enough security; we need full- > fledged multi-level-security, role-based-access-control, and specific > per-daemon MAC restrictions. Sounds like more of what SELinux is good for. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > Ergo the only > > > people who should be writing security policy for deployment are those > > > people who have studied and trained in the stuff. Those people are > > > also known as "security professionals". > > > > If only security professionals can use the system you have failed > > to provide a general purpose facility. It may have value in limited > > circumstances but it is not for everybody. > > But that's okay. Maybe SElinux is not simple enough to use for > everyone, but that does not mean you can't auto-generate policy from > something else, "easy to understand". IOW smack may be great idea, Thank you. > but you written it in wrong language. You > written it in C, while you should have written it in SELinux policy > language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote: On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as "securing the 2M lines of code". The part that Kyle forgot was what most evals these days call the "protection profile" - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of "return(permitted);" for everything may be quite sufficient. Well, in this case the "box" I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. (Of course, I also have boxes where "the SELinux reference policy with all the MCS extensions plus all the LSPP work" is someplace I'm trying to get to). Well, for some of the systems we distribute, "all the MCS extensions plus all the LSPP work" is nowhere near enough security; we need full- fledged multi-level-security, role-based-access-control, and specific per-daemon MAC restrictions. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Hi! > > Ergo the only > > people who should be writing security policy for deployment are those > > people who have studied and trained in the stuff. Those people are > > also known as "security professionals". > > If only security professionals can use the system you have failed > to provide a general purpose facility. It may have value in limited > circumstances but it is not for everybody. But that's okay. Maybe SElinux is not simple enough to use for everyone, but that does not mean you can't auto-generate policy from something else, "easy to understand". IOW smack may be great idea, but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: Well, in this case the box I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff. These are requirements more of the give the client warm fuzzies. On the other hand, when designing a box that could theoretically be run on a semi-public unclassified network and yet still be safe enough to run classified data over IPsec links, you want to give the client all the warm fuzzies they ask for and more. I mean, if the requirement is anything short of runs SELinux I have good reason to believe that a Smack based system is up to it. up to it, yes, but I think you'll find that beyond the simplest policies, an SELinux policy that properly uses the SELinux infrastructure will be much shorter than the equivalent SMACK policy, not even including all the things that SELinux does and SMACK doesn't. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot. Well, given that 99.9% of the systems people are really concerned about security on are multi-user general-purpose machines chuck full of legacy software, that seems to work just fine. If it's a single- user box then you don't even need MAC, just a firewall, a good locked rack/case/keyboard/etc, and decent physical security. If it's entirely custom-controlled software then you can just implement the MAC entirely in your own software. General-purpose vs special- purpose is debatable, so I'll just leave that one lie. Replying to another email: but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. There is no one answer to this question in software development. Generally you prioritize things based on maximizing maintainability and speed and minimizing code, bugs, and complexity. Those are often both conflicting and in agreement. Here are a few common examples of simple-thing-on-complex-thing: * pthreads on top of clone() * open(some_string) on top of all the complex VFS machinery * netcat on top of the vast Linux network stack including support for arbitrary packet filtering and transformation. In addition, simple is undesirable if it makes the implementation less generic for no good reason. Would you want to use the simple MS Windows disk-drive model under Linux? Every disk is its own letter and has its files under it. Oh, you wanted to mount a filesystem over C:\tmp? Sorry, we don't support that, too bad. Under Linux we have a very flexible and powerful VFS which lets you do very crazy things, and then for the user's convenience we have various simple interfaces (like Gnome/KDE/XFCE). Software development is very much about finding the Right Model(TM) to underlie the system, and then building any simplifications-to-the- user on top of the very simple model. Look at the SELinux model again; it has the following things: (A) Labels on almost-all user-visible kernel objects (B) Individual access rules for almost every operation on those objects (C) Transition rules to set the label on newly created objects. (D) Fundamental constraints which enforce hard limits on what may be permitted with allow rules From a fundamental standpoint it's harder to get much simpler than that. On top of that model, we also have a bit of additional *flexibility* for MLS/RBAC, although that flexibility may be ignored completely. (1) You can define users which may only assume some roles (2) You can define roles may only run in some types (3) There's a simple way of declaring multiple levels and dominance. So you see, SELinux is a pretty fundamental description of the degrees of flexibility needed to secure everything. That kind of FUNDAMENTAL description is what belongs in the kernel. Anything else can and should be built on top with better libraries and/or user interfaces.
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: Well, in this case the box I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff. These are requirements more of the give the client warm fuzzies. OK, that's perfectly reasonable. If the client has been sold on the concept of SELinux the client will get warm fuzzies only from SELinux. Security is how you feel about it, after all. On the other hand, when designing a box that could theoretically be run on a semi-public unclassified network and yet still be safe enough to run classified data over IPsec links, you want to give the client all the warm fuzzies they ask for and more. Yes. Of course, a little hard technology behind it doesn't hurt, either. I mean, if the requirement is anything short of runs SELinux I have good reason to believe that a Smack based system is up to it. up to it, yes, but I think you'll find that beyond the simplest policies, an SELinux policy that properly uses the SELinux infrastructure will be much shorter than the equivalent SMACK policy, Well, I find that hard to believe. Maybe I'm only thinking of what you would consider the simplest policies. not even including all the things that SELinux does and SMACK doesn't. Of course. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot. Well, given that 99.9% of the systems people are really concerned about security on are multi-user general-purpose machines chuck full of legacy software, that seems to work just fine. Err, no. By unit count such systems are extremely rare. There is tremendous concern for security in your cell phone, your DVR, your PDA, and even your toaster. If it's a single- user box then you don't even need MAC, just a firewall, a good locked rack/case/keyboard/etc, and decent physical security. You cell phone has really lousy physical security. If it's entirely custom-controlled software then you can just implement the MAC entirely in your own software. General-purpose vs special- purpose is debatable, so I'll just leave that one lie. Indeed. Total control over the software on your phone is not a competetive option for a provider. Replying to another email: but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. There is no one answer to this question in software development. You're correct. Can I quote you on that? Generally you prioritize things based on maximizing maintainability and speed and minimizing code, bugs, and complexity. Those are often both conflicting and in agreement. Here are a few common examples of simple-thing-on-complex-thing: ... Look at the SELinux model again; it has the following things: (A) Labels on almost-all user-visible kernel objects (B) Individual access rules for almost every operation on those objects (C) Transition rules to set the label on newly created objects. (D) Fundamental constraints which enforce hard limits on what may be permitted with allow rules From a fundamental standpoint it's harder to get much simpler than that. It's easy to get simpler than that: (A) Labels on all objects and subjects (B) Access rules for subjects and objects No transformations. Operations in terms of rwx. lots simpler. On top of that model, we also have a bit of additional *flexibility* for MLS/RBAC, although that flexibility may be ignored completely. (1) You can define users which may only assume some roles (2) You can define roles may only run in some types (3) There's a simple way of declaring multiple levels and dominance. So you see, SELinux is a pretty fundamental description of the degrees of flexibility needed to secure everything. That kind of
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Hi! Ergo the only people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as security professionals. If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody. But that's okay. Maybe SElinux is not simple enough to use for everyone, but that does not mean you can't auto-generate policy from something else, easy to understand. IOW smack may be great idea, but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote: On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as securing the 2M lines of code. The part that Kyle forgot was what most evals these days call the protection profile - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of return(permitted); for everything may be quite sufficient. Well, in this case the box I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. (Of course, I also have boxes where the SELinux reference policy with all the MCS extensions plus all the LSPP work is someplace I'm trying to get to). Well, for some of the systems we distribute, all the MCS extensions plus all the LSPP work is nowhere near enough security; we need full- fledged multi-level-security, role-based-access-control, and specific per-daemon MAC restrictions. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek [EMAIL PROTECTED] wrote: Hi! Ergo the only people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as security professionals. If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody. But that's okay. Maybe SElinux is not simple enough to use for everyone, but that does not mean you can't auto-generate policy from something else, easy to understand. IOW smack may be great idea, Thank you. but you written it in wrong language. You written it in C, while you should have written it in SELinux policy language (and your favourite scripting language as frontend). I have often marvelled at the notion of a simplification layer. I believe that you build complex things on top of simple things, not the other way around. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote: On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as securing the 2M lines of code. The part that Kyle forgot was what most evals these days call the protection profile - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of return(permitted); for everything may be quite sufficient. Well, in this case the box I want to secure will eventually be running multi-user X on a multi-level-with-IPsec network. For that kind of protection profile, there is presently no substitute for SELinux with some X11 patches. AppArmor certainly doesn't meet the confidentiality requirements (no data labelling), and SMACK has no way of doing the very tight per-syscall security requirements we have to meet. And what requirements would those be? Seriously, I've done Common Criteria and TCSEC evaluations on systems with less flexibility and granularity than Smack that included X, NFSv3, NIS, clusters, and all sorts of spiffy stuff. I mean, if the requirement is anything short of runs SELinux I have good reason to believe that a Smack based system is up to it. I didn't make this clear initially but that is the kind of system I'm talking about wanting to secure some 50 million lines of code on. Cool. SELinux provides one approach to dealing with that, and the huge multiuser general purpose machine chuck full of legacy software hits the SELinux sweet spot. (Of course, I also have boxes where the SELinux reference policy with all the MCS extensions plus all the LSPP work is someplace I'm trying to get to). Well, for some of the systems we distribute, all the MCS extensions plus all the LSPP work is nowhere near enough security; we need full- fledged multi-level-security, role-based-access-control, and specific per-daemon MAC restrictions. Sounds like more of what SELinux is good for. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > Finally moved back in and with internet. Yay! > > On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote: > > It would not surprise me particularly much if Kyle or someone like > > him could produce a perl script that could generate an SELinux > > policy that, when added to the reference policy on a system > > described by the reference policy, could do a fair imitation of the > > Smack scheme. > > Umm, when did I ever say "emulate smack on top of the reference > policy"? I state categorically that I can write an estimated 500 > line perl script which will generate a standalone SELinux policy > based directly on a smack ruleset. Even better. > It would require no additional > policy beyond what the script outputs, and the script would be only > roughly 500 lines so it can't contain all that much direct source-to- > output text. Better still. > I've started tinkering with that perl script, though I probably won't > get it finished till tomorrow or sunday. Ok. I've been a developement manager, so I'll expect it Thursday. (That's a Pointy Haired Manager joke, BTW) > > One point that I would like to make clear however is that the > > requirement for a 400,000 line reference policy for a jumping off > > point is one of the reasons for Smack. > > There is no "requirement" for a 400,000-line reference policy to > reproduce exactly the behavior of SMACK. The SMACK architecture is > trivial I prefer "simple" over "trivial", but yes, you have the nut of it. > and therefore the SELinux policy is also simple. Well, that's what the exercise is out to demonstrate. I admit to being curious to see the proposed policy. > >> and argue that SMACK is better, anyway, because of its > >> simplicity / speed / something. > > > > My understanding of the current SELinux philosophy is that policy > > should only be written by professionals, and that this was "always" > > the intention. I respect that, and for policy that requires the > > level of sophistication that SELinux does I would have a hard time > > arguing otherwise. > > I can also state categorically that given the set of all admins, > users, and software developers, hardly a fraction of them are > qualified to write security policy at all. I can understand your postion on the SELinux policy. > Hell, most admins and > software developers can't get SUID binaries right, Sadly true. > and that's a > thousand times simpler than a MAC security policy. Now you see, I don't agree with that. It's simpler than an SELinux policy. It's not simpler than a Bell & LaPadula (once we were able to get past the initial resistance to MAC and get someone a three day training class they were able to do some cool things) and it's certainly not simpler than Smack. > Ergo the only > people who should be writing security policy for deployment are those > people who have studied and trained in the stuff. Those people are > also known as "security professionals". If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody. > > One of the things that limited the widespread adoption of MLS > > systems was that the policy, even one as simple as Bell & LaPadula, > > was considered to complex for most uses. I do not see that SELinux, > > or AppArmor for that matter, addresses this fundimental impediment > > to the use of mandatory access control. Yes, you can do just about > > anything with the right combination of classes, booleans, and other > > interesting facilities, but you can't do simple things directly. > > Neither security nor your average distro nowadays is "simple" by any > stretch of the imagination. Hell, my desktop system hits at least 2 > million unique lines of code during boot, let alone logging in to > XFCE. If you can show me a security system other than SELinux which > is sufficiently flexible to secure those 2 million lines of code > along with the other 50 million lines of code found in various pieces > of software on my Debian box then I'll go put on my dunce hat and sit > in the corner. It is my position that the SELinux reference policy fails the "small enough to analyze" clause of the TCB principle. As a result SELinux does not help me feel secure. Restating the complexity of the applications in the policy is arguably an improvement, but I can't help but think the effort would be better put into fixing the applications. So long as your definition of "secure" allows for something other than "runs SELinux", and so long as you are willing to accept the conclusions of "security professionals", I can point to several examples of systems that have been evaluated using other mechanisms. There aren't other mechanisms upstream in Linux yet. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: Finally moved back in and with internet. Yay! On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote: It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme. Umm, when did I ever say emulate smack on top of the reference policy? I state categorically that I can write an estimated 500 line perl script which will generate a standalone SELinux policy based directly on a smack ruleset. Even better. It would require no additional policy beyond what the script outputs, and the script would be only roughly 500 lines so it can't contain all that much direct source-to- output text. Better still. I've started tinkering with that perl script, though I probably won't get it finished till tomorrow or sunday. Ok. I've been a developement manager, so I'll expect it Thursday. (That's a Pointy Haired Manager joke, BTW) One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack. There is no requirement for a 400,000-line reference policy to reproduce exactly the behavior of SMACK. The SMACK architecture is trivial I prefer simple over trivial, but yes, you have the nut of it. and therefore the SELinux policy is also simple. Well, that's what the exercise is out to demonstrate. I admit to being curious to see the proposed policy. and argue that SMACK is better, anyway, because of its simplicity / speed / something. My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was always the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise. I can also state categorically that given the set of all admins, users, and software developers, hardly a fraction of them are qualified to write security policy at all. I can understand your postion on the SELinux policy. Hell, most admins and software developers can't get SUID binaries right, Sadly true. and that's a thousand times simpler than a MAC security policy. Now you see, I don't agree with that. It's simpler than an SELinux policy. It's not simpler than a Bell LaPadula (once we were able to get past the initial resistance to MAC and get someone a three day training class they were able to do some cool things) and it's certainly not simpler than Smack. Ergo the only people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as security professionals. If only security professionals can use the system you have failed to provide a general purpose facility. It may have value in limited circumstances but it is not for everybody. One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly. Neither security nor your average distro nowadays is simple by any stretch of the imagination. Hell, my desktop system hits at least 2 million unique lines of code during boot, let alone logging in to XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. It is my position that the SELinux reference policy fails the small enough to analyze clause of the TCB principle. As a result SELinux does not help me feel secure. Restating the complexity of the applications in the policy is arguably an improvement, but I can't help but think the effort would be better put into fixing the applications. So long as your definition of secure allows for something other than runs SELinux, and so long as you are willing to accept the conclusions of security professionals, I can point to several examples of systems that have been evaluated using other mechanisms. There aren't other mechanisms upstream in Linux yet. 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
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: > XFCE. If you can show me a security system other than SELinux which > is sufficiently flexible to secure those 2 million lines of code > along with the other 50 million lines of code found in various pieces > of software on my Debian box then I'll go put on my dunce hat and sit > in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as "securing the 2M lines of code". The part that Kyle forgot was what most evals these days call the "protection profile" - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of "return(permitted);" for everything may be quite sufficient. (Of course, I also have boxes where "the SELinux reference policy with all the MCS extensions plus all the LSPP work" is someplace I'm trying to get to). pgpimMGzUVBKj.pgp Description: PGP signature
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said: XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. /me hands Kyle a dunce cap. :) Unfortunately, I have to agree that both AppArmor and Smack have at least the potential of qualifying as securing the 2M lines of code. The part that Kyle forgot was what most evals these days call the protection profile - What's the threat model, who are you defending against, and just how good a job does it have to do? I'll posit that for a computer that is (a) not networked, (b) doesn't process sensitive information, and (c) has reasonable physical security, a security policy of return(permitted); for everything may be quite sufficient. (Of course, I also have boxes where the SELinux reference policy with all the MCS extensions plus all the LSPP work is someplace I'm trying to get to). pgpimMGzUVBKj.pgp Description: PGP signature
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Finally moved back in and with internet. Yay! On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote: It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme. Umm, when did I ever say "emulate smack on top of the reference policy"? I state categorically that I can write an estimated 500 line perl script which will generate a standalone SELinux policy based directly on a smack ruleset. It would require no additional policy beyond what the script outputs, and the script would be only roughly 500 lines so it can't contain all that much direct source-to- output text. I've started tinkering with that perl script, though I probably won't get it finished till tomorrow or sunday. One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack. There is no "requirement" for a 400,000-line reference policy to reproduce exactly the behavior of SMACK. The SMACK architecture is trivial and therefore the SELinux policy is also simple. and argue that SMACK is better, anyway, because of its simplicity / speed / something. My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was "always" the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise. I can also state categorically that given the set of all admins, users, and software developers, hardly a fraction of them are qualified to write security policy at all. Hell, most admins and software developers can't get SUID binaries right, and that's a thousand times simpler than a MAC security policy. Ergo the only people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as "security professionals". One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell & LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly. Neither security nor your average distro nowadays is "simple" by any stretch of the imagination. Hell, my desktop system hits at least 2 million unique lines of code during boot, let alone logging in to XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Btw, at: diff -uprN -X linux-2.6.22-base/Documentation/dontdiff linux-2.6.22-base/security/smack/Kconfig linux-2.6.22/security/smack/Kconfig --- linux-2.6.22-base/security/smack/Kconfig1969-12-31 16:00:00.0 -0800 +++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.0 -0700 @@ -0,0 +1,10 @@ +config SECURITY_SMACK + bool "Simplified Mandatory Access Control Kernel Support" + depends on NETLABEL && SECURITY_NETWORK + default n + help + This selects the Simplified Mandatory Access Control Kernel. + SMACK is useful for sensitivity, integrity, and a variety + of other madatory security schemes. + If you are unsure how to answer this question, answer N. + change: + of other madatory security schemes. to: + of other mandatory security schemes. -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Btw, at: diff -uprN -X linux-2.6.22-base/Documentation/dontdiff linux-2.6.22-base/security/smack/Kconfig linux-2.6.22/security/smack/Kconfig --- linux-2.6.22-base/security/smack/Kconfig1969-12-31 16:00:00.0 -0800 +++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.0 -0700 @@ -0,0 +1,10 @@ +config SECURITY_SMACK + bool Simplified Mandatory Access Control Kernel Support + depends on NETLABEL SECURITY_NETWORK + default n + help + This selects the Simplified Mandatory Access Control Kernel. + SMACK is useful for sensitivity, integrity, and a variety + of other madatory security schemes. + If you are unsure how to answer this question, answer N. + change: + of other madatory security schemes. to: + of other mandatory security schemes. -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Finally moved back in and with internet. Yay! On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote: It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme. Umm, when did I ever say emulate smack on top of the reference policy? I state categorically that I can write an estimated 500 line perl script which will generate a standalone SELinux policy based directly on a smack ruleset. It would require no additional policy beyond what the script outputs, and the script would be only roughly 500 lines so it can't contain all that much direct source-to- output text. I've started tinkering with that perl script, though I probably won't get it finished till tomorrow or sunday. One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack. There is no requirement for a 400,000-line reference policy to reproduce exactly the behavior of SMACK. The SMACK architecture is trivial and therefore the SELinux policy is also simple. and argue that SMACK is better, anyway, because of its simplicity / speed / something. My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was always the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise. I can also state categorically that given the set of all admins, users, and software developers, hardly a fraction of them are qualified to write security policy at all. Hell, most admins and software developers can't get SUID binaries right, and that's a thousand times simpler than a MAC security policy. Ergo the only people who should be writing security policy for deployment are those people who have studied and trained in the stuff. Those people are also known as security professionals. One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly. Neither security nor your average distro nowadays is simple by any stretch of the imagination. Hell, my desktop system hits at least 2 million unique lines of code during boot, let alone logging in to XFCE. If you can show me a security system other than SELinux which is sufficiently flexible to secure those 2 million lines of code along with the other 50 million lines of code found in various pieces of software on my Debian box then I'll go put on my dunce hat and sit in the corner. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > I will write you a Perl script which will generate a complete > > > and functionally equivalent SELinux policy (assuming I have enough > > > free time) given a file with your policy language. But I can do this > > > if and only if you tell me which of the SELinux access vectors you > > > care about (In other words, which of the LSM hooks you want to > > > require "read", "write", or "execute" privileges for). With such a > > > little script you could write all the "simplified" policy you want, > > > without having to change the kernel code at all. > > > > It's all spelled out in the module. Go wild. > > Kyle claims he can emulate SMACK with SELinux + perl script, but I > don't think it is fair to force him to write that perl. It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme. One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack. Another point that I think is important, and the rationale behind my being a butt on this (sorry, Kyle, I knew some one would come after me like this, I wasn't aiming at you) is that I have seen several cases where the flexability and capability of SELinux policy has been asserted but the followthrough was missing. I am interested in seeing what an SELinux policy to do what Smack does would look like. I personally though it would be easier to write an LSM than to write that policy. > You want the > code merged, so it should be up to you to do the work... or > acknowledge that selinux ineed is smack supperset I acknowledge that I do not know how to prove that there is no way, using any and all of the facilities of SELinux, to duplicate any particular facility of Smack. I do not acknowledge it as a superset. I am not convinced that all of the proposed SELinux eqivalence claims would actually result in working systems. > and argue that SMACK > is better, anyway, because of its simplicity / speed / something. My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was "always" the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise. One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell & LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly. I was actually quite pleased to see the beginings of an SELinux policy "equivalent" for Smack. I am disappointed that there is insufficient wind in the sails to follow through with it. I would like to compare, contrast, and benchmark against it. I just don't want to write it. > Or maybe that perl script is impossible to write for some reason? Tell > us if so... Goodness Pavel, it's perl! A good sysadmin can do anything in perl! Seriously, maybe he could do it. For the reasons above, I'd be happy to see the attempt. I would love to debate the Smack vs. SELinux question with real data. I am not much concerned with comparisons based on assertion and speculation. I have gotten some very good, meaty comparison data for guardbox applications (Thanks Joshua) and I look forward to more. > Pavel > (who is no security expert) You just don't want the rock star lifestyle. ... And thank you for suggestions. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Hi! > > I will write you a Perl script which will generate a complete > > and functionally equivalent SELinux policy (assuming I have enough > > free time) given a file with your policy language. But I can do this > > if and only if you tell me which of the SELinux access vectors you > > care about (In other words, which of the LSM hooks you want to > > require "read", "write", or "execute" privileges for). With such a > > little script you could write all the "simplified" policy you want, > > without having to change the kernel code at all. > > It's all spelled out in the module. Go wild. Kyle claims he can emulate SMACK with SELinux + perl script, but I don't think it is fair to force him to write that perl. You want the code merged, so it should be up to you to do the work... or acknowledge that selinux ineed is smack supperset and argue that SMACK is better, anyway, because of its simplicity / speed / something. Or maybe that perl script is impossible to write for some reason? Tell us if so... Pavel (who is no security expert) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Hi! I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require read, write, or execute privileges for). With such a little script you could write all the simplified policy you want, without having to change the kernel code at all. It's all spelled out in the module. Go wild. Kyle claims he can emulate SMACK with SELinux + perl script, but I don't think it is fair to force him to write that perl. You want the code merged, so it should be up to you to do the work... or acknowledge that selinux ineed is smack supperset and argue that SMACK is better, anyway, because of its simplicity / speed / something. Or maybe that perl script is impossible to write for some reason? Tell us if so... Pavel (who is no security expert) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Pavel Machek [EMAIL PROTECTED] wrote: Hi! I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require read, write, or execute privileges for). With such a little script you could write all the simplified policy you want, without having to change the kernel code at all. It's all spelled out in the module. Go wild. Kyle claims he can emulate SMACK with SELinux + perl script, but I don't think it is fair to force him to write that perl. It would not surprise me particularly much if Kyle or someone like him could produce a perl script that could generate an SELinux policy that, when added to the reference policy on a system described by the reference policy, could do a fair imitation of the Smack scheme. One point that I would like to make clear however is that the requirement for a 400,000 line reference policy for a jumping off point is one of the reasons for Smack. Another point that I think is important, and the rationale behind my being a butt on this (sorry, Kyle, I knew some one would come after me like this, I wasn't aiming at you) is that I have seen several cases where the flexability and capability of SELinux policy has been asserted but the followthrough was missing. I am interested in seeing what an SELinux policy to do what Smack does would look like. I personally though it would be easier to write an LSM than to write that policy. You want the code merged, so it should be up to you to do the work... or acknowledge that selinux ineed is smack supperset I acknowledge that I do not know how to prove that there is no way, using any and all of the facilities of SELinux, to duplicate any particular facility of Smack. I do not acknowledge it as a superset. I am not convinced that all of the proposed SELinux eqivalence claims would actually result in working systems. and argue that SMACK is better, anyway, because of its simplicity / speed / something. My understanding of the current SELinux philosophy is that policy should only be written by professionals, and that this was always the intention. I respect that, and for policy that requires the level of sophistication that SELinux does I would have a hard time arguing otherwise. One of the things that limited the widespread adoption of MLS systems was that the policy, even one as simple as Bell LaPadula, was considered to complex for most uses. I do not see that SELinux, or AppArmor for that matter, addresses this fundimental impediment to the use of mandatory access control. Yes, you can do just about anything with the right combination of classes, booleans, and other interesting facilities, but you can't do simple things directly. I was actually quite pleased to see the beginings of an SELinux policy equivalent for Smack. I am disappointed that there is insufficient wind in the sails to follow through with it. I would like to compare, contrast, and benchmark against it. I just don't want to write it. Or maybe that perl script is impossible to write for some reason? Tell us if so... Goodness Pavel, it's perl! A good sysadmin can do anything in perl! Seriously, maybe he could do it. For the reasons above, I'd be happy to see the attempt. I would love to debate the Smack vs. SELinux question with real data. I am not much concerned with comparisons based on assertion and speculation. I have gotten some very good, meaty comparison data for guardbox applications (Thanks Joshua) and I look forward to more. Pavel (who is no security expert) You just don't want the rock star lifestyle. ... And thank you for suggestions. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > > > If you have no interest in categorizing the SELinux access vectors, > then how do you expect to categorize the LSM hooks, which are almost > 1-to-1 mapped with the SELinux access vectors? Those that refer to object accesses and those that do not. The former are generally interesting, the latter are generally not. That's a rule of thumb, mind you. Anyway, have a look at the hook table, it's in smack_lsm.c > > The point you make, that you need to have that in order to create a > > policy description, is one of the reasons for Smack. Simplified. > > Well yes, but a simplified policy is useless if it uses no LSM > hooks. As above, that's smack_lsm.c, a little over 2000 lines of good old fashioned C code. > I will write you a Perl script which will generate a complete > and functionally equivalent SELinux policy (assuming I have enough > free time) given a file with your policy language. But I can do this > if and only if you tell me which of the SELinux access vectors you > care about (In other words, which of the LSM hooks you want to > require "read", "write", or "execute" privileges for). With such a > little script you could write all the "simplified" policy you want, > without having to change the kernel code at all. It's all spelled out in the module. Go wild. > > > My point is your policy format is SO simple it doesn't even need the > SELinux MLS code to handle it. From the way you've described it the > base policy (~200 lines) would be *identical* regardless of the > entries in your policy language, and the rest could be generated by a > script directly from the "C Unclass rx"-type stuff. Ok. > >> Whoops, I think I must have smashed the delete key or something > >> while sending. Here's the paragraphs which got elided: > >> > >> Well, yes, but a policy which completely ignores future > >> expandability can't be expanded upon regardless. It would also be > >> very hard to add new policy without a lot of duplication under > >> your system. On the other hand, with SELinux you can very easily > >> add attribute-based policy so adding new capabilities is as simple > >> as sticking existing attributes on newly defined types. For example: > >> > >> type my_log_t, file_type, log_file; > >> type my_log_daemon, daemon; > >> > >> Right there I just gave permission for the logrotate to recycle > >> files labelled my_log_t, which the sysadmin and audit admin can > >> also read (and the audit admin can delete). I also gave > >> permission for my daemon to send SIGCHLD to init, and for init/ > >> initscripts to send it a SIGTERM/SIGQUIT. All without writing a > >> SINGLE policy rule. Basically all of those existing behaviors are > >> found in allow rules built on the "file_type", "log_file", and > >> "daemon" attributes. > > > > Ah, now you're refering to the reference policy, right? > > Yes, precisely. For most of that functionality there are existing > attributes and types defined in the reference policy to make custom > policy much easier. Furthermore, there are interface files which > allow me to say something like "Let this program spawn an Apache > daemon in the right domain" with a single line. If I only want to do > that when the "httpd" module is loaded I can put the line in an > "optional" block. A policy for a basic network daemon with a couple > log files, a config file, and a little database is all of 30 lines, > maybe 50 if you throw in comments. After you have the 400,000 lines of reference policy behind it. > >>> They can be added or changed one by one as required while the > >>> system is running, and there are uses that exploit that. One > >>> example is to put the label "Game" on certain programs and: > >>> > >>>at 8:00am "Worker Game no" > >>>at 5:00pm "Worker Game x" > >>> > >>> Thus Worker processes can access Game files only during off hours. > >> > >> This is fundamentally broken: > >> [...] > >> Secondly, you can already do the same thing with DAC and a PAM > >> groups-from-time-of-day module, I don't see why such a thing is > >> special enough to need MAC. Thirdly, I could do exactly the same > >> thing with an SELinux boolean and a cronjob (once we get proper > >> revoke support): > > > > There is usually a way to address any particular problem using DAC, > > it's often sufficiently painful that MAC looks like a better approach. > > No, generally the only reason to use MAC is when it's security- > critical (system compromise, classified data, critical > infrastructure, etc). Denying users access to games during the > workday is hardly "security-critical". If that system's CPU time was > exclusively needed for a life support machine during the day then > maybe, but that's what renice or realtime scheduling are for and why > the hell are you installing games on a heart monitor? HeeHee. Don't think heart
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 22:36:15, Joshua Brindle wrote: Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. Yeah, I figured this out a couple minutes ago. Turns out you can get a similar effect with a little properly labeled shell script though (text included in my last email), but it does decrease overall system security. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks. I will be happy to consider your arguement when you are willing to present the complete argument. Here's my complete argument: Regardless of how you categorize "read", "write", "execute", and "doesnt-need-protection" in your policy language, I can write an SELinux policy and a list of labels which expresses that policy. Moreover, without too much work I can probably write a Perl script to do it for you. On the other hand I can only do that if you tell me exactly how you want to categorize those things, though. In my personal opinion they cannot be reasonably categorized without breaking all sorts of tools or leaving gaping holes; precisely the reason that SELinux uses such a fine-grained list. This identifies an important design philosophy issue, that being what granularity is appropriate. I have no interest in composing a description of Smack at the granularity that SELinux uses. If you have no interest in categorizing the SELinux access vectors, then how do you expect to categorize the LSM hooks, which are almost 1-to-1 mapped with the SELinux access vectors? The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified. Well yes, but a simplified policy is useless if it uses no LSM hooks. I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require "read", "write", or "execute" privileges for). With such a little script you could write all the "simplified" policy you want, without having to change the kernel code at all. Ok, you want sample policy to match your "MLS" sample? For convenience here's one more macro: define(`rx',`r(`$1',`$2') x(`$1',`$2')') type unclass; type c; type s; type ts; rx(c, unclass) rx(s, c) rx(s, unclass) rx(ts, s) rx(ts, c) rx(ts, unclass) In case you don't have the policy you typed into your email, it looks almost identical with a few exceptions for slightly modified syntax: CUnclass rx SC rx SUnclass rx TS S rx TS C rx TS Unclass rx Yup. Your macro invocations look very much like the Smack specification. Your macro definitions are of course unnecessary in Smack, and you really ought to be using the MLS labels SELinux supports, and you need a base policy underneath this. My point is your policy format is SO simple it doesn't even need the SELinux MLS code to handle it. From the way you've described it the base policy (~200 lines) would be *identical* regardless of the entries in your policy language, and the rest could be generated by a script directly from the "C Unclass rx"-type stuff. Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided: Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example: type my_log_t, file_type, log_file; type my_log_daemon, daemon; Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/ initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the "file_type", "log_file", and "daemon" attributes. Ah, now you're refering to the reference policy, right? Yes, precisely. For most of that functionality there are existing attributes and types defined in the reference policy to make custom policy much easier. Furthermore, there are interface files which allow me to say something like "Let this program spawn an Apache daemon in the right domain" with a single line. If I only want to do that when the "httpd" module is loaded I can put the line in an "optional" block. A policy for a basic network daemon with a couple log files, a
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler wrote: > I respect the design decisions that SELinux has made regarding > granularity without agreeing with them myself. > It isn't even an exclusive decision: both design points can be "right", but aimed at different use cases. Which is why LSM exists, so users can decide on an appropriate mechanism. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: > > > > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > > Entries are never deleted, although they can be modified. > > > > > > The modification case still seems racy then. > > > > Fair enough. I'll look into real list management. > > You don't necessarily need more list management if you don't > plan to remove entries, but just replace them. > > e.g. what could work to atomically replace is: > > - Make the buffer a pointer to an allocated buffer that also > contains a struct rcu_head. > - Reader: Does rcu_read_lock() around list walk (that just disables > preemption on preemptible kernels and is otherwise a nop). > Also uses rcu_reference for reading the pointer. > - Writer: Continues using the mutex to protect against other writers. > When changing an entry allocate a new buffer + rcu_head. Initialize > buffer. Replace pointer. Free old buffer using call_rcu() > > The RCU would just make sure the buffer is not freed while other > CPUs are still accessing it. It also means they can use stale > rules for a time, but it is a strictly bounded time > (bounded to max time walking the list plus max time any interrupt > handlers inbetween run [admittedly that can be very long in theory, > but it's all logically only a single rule check]) Thank you. You have no idea how helpful that little suggestion was. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: > > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > Entries are never deleted, although they can be modified. > > > > The modification case still seems racy then. > > Fair enough. I'll look into real list management. You don't necessarily need more list management if you don't plan to remove entries, but just replace them. e.g. what could work to atomically replace is: - Make the buffer a pointer to an allocated buffer that also contains a struct rcu_head. - Reader: Does rcu_read_lock() around list walk (that just disables preemption on preemptible kernels and is otherwise a nop). Also uses rcu_reference for reading the pointer. - Writer: Continues using the mutex to protect against other writers. When changing an entry allocate a new buffer + rcu_head. Initialize buffer. Replace pointer. Free old buffer using call_rcu() The RCU would just make sure the buffer is not freed while other CPUs are still accessing it. It also means they can use stale rules for a time, but it is a strictly bounded time (bounded to max time walking the list plus max time any interrupt handlers inbetween run [admittedly that can be very long in theory, but it's all logically only a single rule check]) -Andi - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> >+static int smack_task_movememory(struct task_struct *p)
> >> >+{
> >> >+ int rc;
> >> >+
> >> >+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
> >> >+ return rc;
> >> >+}
> >>
> >> Uh...
> >>
> >> {
> >>return smk_curacc(smk_of_task(p), MAY_WRITE);
> >> }
> >>
> >> (also others)
> >
> >That was a little excessive, wasn't it?
>
> How do you mean? I was just suggesting to collapse the three [four] lines
> into
> one, getting rid of the tempotemporaries in a lot of these functions,
> for example,
Sorry, I meant that my code was excessive, not your comment.
Your comment was fine and most welcome. I'm sorry that I was
unclear and sounded defensive.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Linus and AKPM pulled from CC, I'm sure they're bored to tears by
> now ;-).
Yeah.
> On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
> > --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> >> On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
> >>> It would be instructive for those who are not well versed in the
> >>> nuances of SELinux policy if you actually spelled out the whole
> >>> thing, rather than using "## and more ##". Part of the point of
> >>> Smack is the makeup of the full list that would be required here.
> >>
> >> Well, yes, but how exactly do you define "read", "write", and
> >> "execute" for the full list of SELinux object classes found here:
> >> http://www.tresys.com/selinux/obj_perms_help.html
> >
> > Smack is designed to treat objects as consistantly as is
> > reasonable. The list of object classes defined by SELinux is great
> > for a system designed to treat accesses with the highest possible
> > granularity. This is not a design goal for Smack.
> >
> >> I was considering compiling the complete list, but such an
> >> exercise would take me at least an hour to do properly and which
> >> categories individual permissions should be placed in could be
> >> argued for weeks.
> >
> > I will be happy to consider your arguement when you are willing to
> > present the complete argument.
>
> Here's my complete argument:
>
> Regardless of how you categorize "read", "write", "execute", and
> "doesnt-need-protection" in your policy language, I can write an
> SELinux policy and a list of labels which expresses that policy.
> Moreover, without too much work I can probably write a Perl script to
> do it for you. On the other hand I can only do that if you tell me
> exactly how you want to categorize those things, though. In my
> personal opinion they cannot be reasonably categorized without
> breaking all sorts of tools or leaving gaping holes; precisely the
> reason that SELinux uses such a fine-grained list.
This identifies an important design philosophy issue, that
being what granularity is appropriate. I have no interest in
composing a description of Smack at the granularity that
SELinux uses. The point you make, that you need to have that
in order to create a policy description, is one of the reasons
for Smack. Simplified.
I respect the design decisions that SELinux has made regarding
granularity without agreeing with them myself.
> >> Specifically, do you classify the bind() syscall as a "read" or a
> >> "write" operation.
> >
> > Neither. Bind attaches a name (port number) to a socket (which is a
> > data structure that is part of your process) from a global
> > namespace. No objects are involved, hence no accesses.
>
> So "bind()" doesn't present a security hole at all and any program
> may bind to any port? Sounds fun! I'm sure lots of crackers would
> love to get ahold of an account on such a web-server; what havoc they
> could wreak! Even the <1024 restriction doesn't sufficiently limit
> things these days, as many critical services use ports >=1024.
Heaven forbid I should put all those firewall writers out of work.
Seriously, the port namespace is completely arbitrary by "design".
> And now to describe these rules:
>
> > Smack defines and uses these labels:
> > "*" - pronounced "star"
> > "_" - pronounced "floor"
> > "^" - pronounced "hat"
> > "?" - pronounced "huh"
> >
> > The access rules enforced by Smack are, in order:
> >
> > 1. Any access requested by a task labeled "*" is denied.
> > 2. A read or execute access requested by a task labeled "^" is
> > permitted.
> > 3. A read or execute access requested on an object labeled "_"
> > is permitted.
> > 4. Any access requested on an object labeled "*" is permitted.
> > 5. Any access requested by a task on an object with the same
> > label is permitted.
> > 6. Any access requested that is explicitly defined in the
> > loaded rule set is permitted.
> > 7. Any other access is denied.
>
> ## These are calls to the above macros which plug in the
> necessary arguments
> r(hat, {*})
> x(hat, {*})
> r(~{star}, floor)
> x(~{star}, floor)
> r(~{star}, star)
> w(~{star}, star)
> x(~{star}, star)
> r(~{star}, self)
> w(~{star}, self)
> x(~{star}, self)
> ## Include your "loaded rule set" here ##
> >>>
> >>> What would that look like?
> >>
> >> The same kind of thing as the r, x, and w above, with occasional
> >> "type my_type_t; role rr types my_type_t;" to declare a type
> >> before use. If you wanted to add support for attributes which
> >> apply to multiple types, you could put those after a comma after
> >> the "type my_type_t" portion of the type declaration.
> >
> > Well, I'm interested in seeing the actual code, not "the same kind
> >
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > > Entries are never deleted, although they can be modified. > > The modification case still seems racy then. Fair enough. I'll look into real list management. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Keith Owens <[EMAIL PROTECTED]> wrote: > Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote: > >Smack is the Simplified Mandatory Access Control Kernel. > > > > [snip] > > > >Smack defines and uses these labels: > > > >"*" - pronounced "star" > >"_" - pronounced "floor" > >"^" - pronounced "hat" > >"?" - pronounced "huh" > > > >The access rules enforced by Smack are, in order: > > > >1. Any access requested by a task labeled "*" is denied. > >2. A read or execute access requested by a task labeled "^" > > is permitted. > >3. A read or execute access requested on an object labeled "_" > > is permitted. > >4. Any access requested on an object labeled "*" is permitted. > >5. Any access requested by a task on an object with the same > > label is permitted. > >6. Any access requested that is explicitly defined in the loaded > > rule set is permitted. > >7. Any other access is denied. > > Some security systems that have the concept of "no default access" > (task labeled "*") also allow access by those tasks but only if there > is an explicit rule giving access to the task. IOW, rule 6 is applied > before rule 1. In my experience this simplifies special cases where a > task should only have access to a very small set of resources. I'm > curious why smack goes the other way? A task labeled star would create files labeled star, which would be readable and writable by everyone (rule 4). This would be bad. Over the past three decade I've seen a lot of secure installations but I have never seen one where they really wanted to deny any real application access to "/". That's a major reason for chrooted environments. Remember also that a process labeled Coffee would have read access to floor files, all access to star files (e.g. /dev/null), read and write access to Coffee objects, and no others unless specified. If you are serious about reducing the programs a Coffee process can run you can do so by moving them off the floor, that is, giving them a different label, say "Tea". There is a cost to doing this, which is that you now have to give other labels explicit access to Tea objects. This is how you would implement a Biba integrity policy. So, can you give me an example where you don't want access to any file system objects (no read or execute access on floor) and are still doing something useful? Remember that you can't exec a program if you can't access it. I think that access to the file system namespace is universally required. I'm open to education. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
> Entries are never deleted, although they can be modified. The modification case still seems racy then. -Andi - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 16:22, Casey Schaufler wrote:
>> >@@ -0,0 +1,8 @@
>> >+#
>> >+# Makefile for the SMACK LSM
>> >+#
>> >+
>> >+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>> >+
>> >+smack-y := smack_lsm.o smack_access.o smackfs.o
>>
>> smack-objs :=
>
>Added.
I should have added "replace it".
>> >+/*
>> >+ * ' \n\0'
>> >+ */
>>
>> I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
>> uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
>> are actually meant as a char[8]? (/me scrathces head)
>
>Yes. "s == o" vs "strcmp(s,o) == 0".
Evil optimization ;-)
[ s == o is memcmp(s, o, sizeof(that)) == 0]
>> >+ char temp[80];
>> >+ ssize_t rc;
>> >+
>> >+ if (*ppos != 0)
>> >+ return 0;
>> >+
>> >+ sprintf(temp, "%d", smk_cipso_doi_value);
>> >+ rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
>>
>> 80 is plenty for a 11 char string.
>>
>> Look, they've got funny ideas! :)
>> net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof("4294967296 65635")];
Proposal would have been: char temp[sizeof("4294967296")];
>> >+extern int smack_net_nltype;
>> >+extern int smack_cipso_direct;
>> >+extern struct smk_cipso_entry *smack_cipso;
>>
>> for consistency reasons, add extern to the other vars too...
>
>the others?
There were some [or some function prototypes] above this point.
>> >+static int smack_task_movememory(struct task_struct *p)
>> >+{
>> >+ int rc;
>> >+
>> >+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
>> >+ return rc;
>> >+}
>>
>> Uh...
>>
>> {
>> return smk_curacc(smk_of_task(p), MAY_WRITE);
>> }
>>
>> (also others)
>
>That was a little excessive, wasn't it?
How do you mean? I was just suggesting to collapse the three [four] lines into
one, getting rid of the tempotemporaries in a lot of these functions,
for example,
>> >+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
>> >+ int sig, u32 secid)
>> >+{
>> >+ smack_t *tsp = smk_of_task(p);
>> >+ int rc;
>> >+
>> >+ /*
>> >+* Sending a signal requires that the sender
>> >+* can write the receiver.
>> >+*/
>> >+ rc = smk_curacc(tsp, MAY_WRITE);
>> >+
>> >+ return rc;
>> >+}
static int smack_task_kill(struct stask_struct *p, struct siginfo *info,
int sig, u32 secid)
{
/* Comment */
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
Jan
--
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 22:36:15, Joshua Brindle wrote: Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your ## lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. Yeah, I figured this out a couple minutes ago. Turns out you can get a similar effect with a little properly labeled shell script though (text included in my last email), but it does decrease overall system security. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your ## lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote: really big snip If you have no interest in categorizing the SELinux access vectors, then how do you expect to categorize the LSM hooks, which are almost 1-to-1 mapped with the SELinux access vectors? Those that refer to object accesses and those that do not. The former are generally interesting, the latter are generally not. That's a rule of thumb, mind you. Anyway, have a look at the hook table, it's in smack_lsm.c The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified. Well yes, but a simplified policy is useless if it uses no LSM hooks. As above, that's smack_lsm.c, a little over 2000 lines of good old fashioned C code. I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require read, write, or execute privileges for). With such a little script you could write all the simplified policy you want, without having to change the kernel code at all. It's all spelled out in the module. Go wild. another major snip My point is your policy format is SO simple it doesn't even need the SELinux MLS code to handle it. From the way you've described it the base policy (~200 lines) would be *identical* regardless of the entries in your policy language, and the rest could be generated by a script directly from the C Unclass rx-type stuff. Ok. Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided: Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example: type my_log_t, file_type, log_file; type my_log_daemon, daemon; Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/ initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the file_type, log_file, and daemon attributes. Ah, now you're refering to the reference policy, right? Yes, precisely. For most of that functionality there are existing attributes and types defined in the reference policy to make custom policy much easier. Furthermore, there are interface files which allow me to say something like Let this program spawn an Apache daemon in the right domain with a single line. If I only want to do that when the httpd module is loaded I can put the line in an optional block. A policy for a basic network daemon with a couple log files, a config file, and a little database is all of 30 lines, maybe 50 if you throw in comments. After you have the 400,000 lines of reference policy behind it. They can be added or changed one by one as required while the system is running, and there are uses that exploit that. One example is to put the label Game on certain programs and: at 8:00am Worker Game no at 5:00pm Worker Game x Thus Worker processes can access Game files only during off hours. This is fundamentally broken: [...] Secondly, you can already do the same thing with DAC and a PAM groups-from-time-of-day module, I don't see why such a thing is special enough to need MAC. Thirdly, I could do exactly the same thing with an SELinux boolean and a cronjob (once we get proper revoke support): There is usually a way to address any particular problem using DAC, it's often sufficiently painful that MAC looks like a better approach. No, generally the only reason to use MAC is when it's security- critical (system compromise, classified data, critical infrastructure, etc). Denying users access to games during the workday is hardly security-critical. If that system's CPU time was exclusively needed for a life support machine during the day then maybe, but that's what renice or realtime scheduling are for and why the hell are you installing games on a heart monitor? HeeHee. Don't think heart monitor, think in-car trip recorder. The games can only be used when the car's at rest. It's a strange world we live in today. Another big snip Yes. This is the way it
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 16:22, Casey Schaufler wrote:
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
Added.
I should have added replace it.
+/*
+ * ' \n\0'
+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
Yes. s == o vs strcmp(s,o) == 0.
Evil optimization ;-)
[ s == o is memcmp(s, o, sizeof(that)) == 0]
+ char temp[80];
+ ssize_t rc;
+
+ if (*ppos != 0)
+ return 0;
+
+ sprintf(temp, %d, smk_cipso_doi_value);
+ rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
80 is plenty for a 11 char string.
Look, they've got funny ideas! :)
net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof(4294967296 65635)];
Proposal would have been: char temp[sizeof(4294967296)];
+extern int smack_net_nltype;
+extern int smack_cipso_direct;
+extern struct smk_cipso_entry *smack_cipso;
for consistency reasons, add extern to the other vars too...
the others?
There were some [or some function prototypes] above this point.
+static int smack_task_movememory(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
Uh...
{
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
(also others)
That was a little excessive, wasn't it?
How do you mean? I was just suggesting to collapse the three [four] lines into
one, getting rid of the tempotemporaries in a lot of these functions,
for example,
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+ int sig, u32 secid)
+{
+ smack_t *tsp = smk_of_task(p);
+ int rc;
+
+ /*
+* Sending a signal requires that the sender
+* can write the receiver.
+*/
+ rc = smk_curacc(tsp, MAY_WRITE);
+
+ return rc;
+}
static int smack_task_kill(struct stask_struct *p, struct siginfo *info,
int sig, u32 secid)
{
/* Comment */
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
Jan
--
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Entries are never deleted, although they can be modified. The modification case still seems racy then. -Andi - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Keith Owens [EMAIL PROTECTED] wrote: Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote: Smack is the Simplified Mandatory Access Control Kernel. [snip] Smack defines and uses these labels: * - pronounced star _ - pronounced floor ^ - pronounced hat ? - pronounced huh The access rules enforced by Smack are, in order: 1. Any access requested by a task labeled * is denied. 2. A read or execute access requested by a task labeled ^ is permitted. 3. A read or execute access requested on an object labeled _ is permitted. 4. Any access requested on an object labeled * is permitted. 5. Any access requested by a task on an object with the same label is permitted. 6. Any access requested that is explicitly defined in the loaded rule set is permitted. 7. Any other access is denied. Some security systems that have the concept of no default access (task labeled *) also allow access by those tasks but only if there is an explicit rule giving access to the task. IOW, rule 6 is applied before rule 1. In my experience this simplifies special cases where a task should only have access to a very small set of resources. I'm curious why smack goes the other way? A task labeled star would create files labeled star, which would be readable and writable by everyone (rule 4). This would be bad. Over the past three decade I've seen a lot of secure installations but I have never seen one where they really wanted to deny any real application access to /. That's a major reason for chrooted environments. Remember also that a process labeled Coffee would have read access to floor files, all access to star files (e.g. /dev/null), read and write access to Coffee objects, and no others unless specified. If you are serious about reducing the programs a Coffee process can run you can do so by moving them off the floor, that is, giving them a different label, say Tea. There is a cost to doing this, which is that you now have to give other labels explicit access to Tea objects. This is how you would implement a Biba integrity policy. So, can you give me an example where you don't want access to any file system objects (no read or execute access on floor) and are still doing something useful? Remember that you can't exec a program if you can't access it. I think that access to the file system namespace is universally required. I'm open to education. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen [EMAIL PROTECTED] wrote: Entries are never deleted, although they can be modified. The modification case still seems racy then. Fair enough. I'll look into real list management. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
Yeah.
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using ## and more ##. Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define read, write, and
execute for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
Smack is designed to treat objects as consistantly as is
reasonable. The list of object classes defined by SELinux is great
for a system designed to treat accesses with the highest possible
granularity. This is not a design goal for Smack.
I was considering compiling the complete list, but such an
exercise would take me at least an hour to do properly and which
categories individual permissions should be placed in could be
argued for weeks.
I will be happy to consider your arguement when you are willing to
present the complete argument.
Here's my complete argument:
Regardless of how you categorize read, write, execute, and
doesnt-need-protection in your policy language, I can write an
SELinux policy and a list of labels which expresses that policy.
Moreover, without too much work I can probably write a Perl script to
do it for you. On the other hand I can only do that if you tell me
exactly how you want to categorize those things, though. In my
personal opinion they cannot be reasonably categorized without
breaking all sorts of tools or leaving gaping holes; precisely the
reason that SELinux uses such a fine-grained list.
This identifies an important design philosophy issue, that
being what granularity is appropriate. I have no interest in
composing a description of Smack at the granularity that
SELinux uses. The point you make, that you need to have that
in order to create a policy description, is one of the reasons
for Smack. Simplified.
I respect the design decisions that SELinux has made regarding
granularity without agreeing with them myself.
Specifically, do you classify the bind() syscall as a read or a
write operation.
Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global
namespace. No objects are involved, hence no accesses.
So bind() doesn't present a security hole at all and any program
may bind to any port? Sounds fun! I'm sure lots of crackers would
love to get ahold of an account on such a web-server; what havoc they
could wreak! Even the 1024 restriction doesn't sufficiently limit
things these days, as many critical services use ports =1024.
Heaven forbid I should put all those firewall writers out of work.
Seriously, the port namespace is completely arbitrary by design.
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^ is
permitted.
3. A read or execute access requested on an object labeled _
is permitted.
4. Any access requested on an object labeled * is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the
loaded rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the
necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your loaded rule set here ##
What would that look like?
The same kind of thing as the r, x, and w above, with occasional
type my_type_t; role rr types my_type_t; to declare a type
before use. If you wanted to add support for attributes which
apply to multiple types, you could put those after a comma after
the type my_type_t portion of the type declaration.
Well, I'm interested in seeing the actual code, not the same kind
of thing as arguement.
Ok, you want sample policy to match your MLS sample? For
convenience here's one more macro:
define(`rx',`r(`$1',`$2') x(`$1',`$2')')
type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)
In case you don't have the policy you typed into your email, it looks
almost identical
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
+static int smack_task_movememory(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
Uh...
{
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
(also others)
That was a little excessive, wasn't it?
How do you mean? I was just suggesting to collapse the three [four] lines
into
one, getting rid of the tempotemporaries in a lot of these functions,
for example,
Sorry, I meant that my code was excessive, not your comment.
Your comment was fine and most welcome. I'm sorry that I was
unclear and sounded defensive.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: --- Andi Kleen [EMAIL PROTECTED] wrote: Entries are never deleted, although they can be modified. The modification case still seems racy then. Fair enough. I'll look into real list management. You don't necessarily need more list management if you don't plan to remove entries, but just replace them. e.g. what could work to atomically replace is: - Make the buffer a pointer to an allocated buffer that also contains a struct rcu_head. - Reader: Does rcu_read_lock() around list walk (that just disables preemption on preemptible kernels and is otherwise a nop). Also uses rcu_reference for reading the pointer. - Writer: Continues using the mutex to protect against other writers. When changing an entry allocate a new buffer + rcu_head. Initialize buffer. Replace pointer. Free old buffer using call_rcu() The RCU would just make sure the buffer is not freed while other CPUs are still accessing it. It also means they can use stale rules for a time, but it is a strictly bounded time (bounded to max time walking the list plus max time any interrupt handlers inbetween run [admittedly that can be very long in theory, but it's all logically only a single rule check]) -Andi - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen [EMAIL PROTECTED] wrote: On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: --- Andi Kleen [EMAIL PROTECTED] wrote: Entries are never deleted, although they can be modified. The modification case still seems racy then. Fair enough. I'll look into real list management. You don't necessarily need more list management if you don't plan to remove entries, but just replace them. e.g. what could work to atomically replace is: - Make the buffer a pointer to an allocated buffer that also contains a struct rcu_head. - Reader: Does rcu_read_lock() around list walk (that just disables preemption on preemptible kernels and is otherwise a nop). Also uses rcu_reference for reading the pointer. - Writer: Continues using the mutex to protect against other writers. When changing an entry allocate a new buffer + rcu_head. Initialize buffer. Replace pointer. Free old buffer using call_rcu() The RCU would just make sure the buffer is not freed while other CPUs are still accessing it. It also means they can use stale rules for a time, but it is a strictly bounded time (bounded to max time walking the list plus max time any interrupt handlers inbetween run [admittedly that can be very long in theory, but it's all logically only a single rule check]) Thank you. You have no idea how helpful that little suggestion was. 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler wrote: I respect the design decisions that SELinux has made regarding granularity without agreeing with them myself. It isn't even an exclusive decision: both design points can be right, but aimed at different use cases. Which is why LSM exists, so users can decide on an appropriate mechanism. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks. I will be happy to consider your arguement when you are willing to present the complete argument. Here's my complete argument: Regardless of how you categorize read, write, execute, and doesnt-need-protection in your policy language, I can write an SELinux policy and a list of labels which expresses that policy. Moreover, without too much work I can probably write a Perl script to do it for you. On the other hand I can only do that if you tell me exactly how you want to categorize those things, though. In my personal opinion they cannot be reasonably categorized without breaking all sorts of tools or leaving gaping holes; precisely the reason that SELinux uses such a fine-grained list. This identifies an important design philosophy issue, that being what granularity is appropriate. I have no interest in composing a description of Smack at the granularity that SELinux uses. If you have no interest in categorizing the SELinux access vectors, then how do you expect to categorize the LSM hooks, which are almost 1-to-1 mapped with the SELinux access vectors? The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified. Well yes, but a simplified policy is useless if it uses no LSM hooks. I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require read, write, or execute privileges for). With such a little script you could write all the simplified policy you want, without having to change the kernel code at all. Ok, you want sample policy to match your MLS sample? For convenience here's one more macro: define(`rx',`r(`$1',`$2') x(`$1',`$2')') type unclass; type c; type s; type ts; rx(c, unclass) rx(s, c) rx(s, unclass) rx(ts, s) rx(ts, c) rx(ts, unclass) In case you don't have the policy you typed into your email, it looks almost identical with a few exceptions for slightly modified syntax: CUnclass rx SC rx SUnclass rx TS S rx TS C rx TS Unclass rx Yup. Your macro invocations look very much like the Smack specification. Your macro definitions are of course unnecessary in Smack, and you really ought to be using the MLS labels SELinux supports, and you need a base policy underneath this. My point is your policy format is SO simple it doesn't even need the SELinux MLS code to handle it. From the way you've described it the base policy (~200 lines) would be *identical* regardless of the entries in your policy language, and the rest could be generated by a script directly from the C Unclass rx-type stuff. Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided: Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example: type my_log_t, file_type, log_file; type my_log_daemon, daemon; Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/ initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the file_type, log_file, and daemon attributes. Ah, now you're refering to the reference policy, right? Yes, precisely. For most of that functionality there are existing attributes and types defined in the reference policy to make custom policy much easier. Furthermore, there are interface files which allow me to say something like Let this program spawn an Apache daemon in the right domain with a single line. If I only want to do that when the httpd module is loaded I can put the line in an optional block. A policy for a basic network daemon with a couple log files, a config file, and a little database
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using "## and more ##". Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define "read", "write", and
"execute" for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
Smack is designed to treat objects as consistantly as is
reasonable. The list of object classes defined by SELinux is great
for a system designed to treat accesses with the highest possible
granularity. This is not a design goal for Smack.
I was considering compiling the complete list, but such an
exercise would take me at least an hour to do properly and which
categories individual permissions should be placed in could be
argued for weeks.
I will be happy to consider your arguement when you are willing to
present the complete argument.
Here's my complete argument:
Regardless of how you categorize "read", "write", "execute", and
"doesnt-need-protection" in your policy language, I can write an
SELinux policy and a list of labels which expresses that policy.
Moreover, without too much work I can probably write a Perl script to
do it for you. On the other hand I can only do that if you tell me
exactly how you want to categorize those things, though. In my
personal opinion they cannot be reasonably categorized without
breaking all sorts of tools or leaving gaping holes; precisely the
reason that SELinux uses such a fine-grained list.
Specifically, do you classify the bind() syscall as a "read" or a
"write" operation.
Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global
namespace. No objects are involved, hence no accesses.
So "bind()" doesn't present a security hole at all and any program
may bind to any port? Sounds fun! I'm sure lots of crackers would
love to get ahold of an account on such a web-server; what havoc they
could wreak! Even the <1024 restriction doesn't sufficiently limit
things these days, as many critical services use ports >=1024.
And now to describe these rules:
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^" is
permitted.
3. A read or execute access requested on an object labeled "_"
is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the
loaded rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the
necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##
What would that look like?
The same kind of thing as the r, x, and w above, with occasional
"type my_type_t; role rr types my_type_t;" to declare a type
before use. If you wanted to add support for attributes which
apply to multiple types, you could put those after a comma after
the "type my_type_t" portion of the type declaration.
Well, I'm interested in seeing the actual code, not "the same kind
of thing" as arguement.
Ok, you want sample policy to match your "MLS" sample? For
convenience here's one more macro:
define(`rx',`r(`$1',`$2') x(`$1',`$2')')
type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)
In case you don't have the policy you typed into your email, it looks
almost identical with a few exceptions for slightly modified syntax:
CUnclass rx
SC rx
SUnclass rx
TS S rx
TS C rx
TS Unclass rx
Smack rule sets can be easily defined that describe
Bell sensitivity, Biba integrity, and a variety of
interesting configurations. Smack rule sets can be modified on
the fly to accomodate changes in the operating environment or
even the time of day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
You have to build the booleans into the policy in advance.
Well, yes,
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote: >Smack is the Simplified Mandatory Access Control Kernel. > > [snip] > >Smack defines and uses these labels: > >"*" - pronounced "star" >"_" - pronounced "floor" >"^" - pronounced "hat" >"?" - pronounced "huh" > >The access rules enforced by Smack are, in order: > >1. Any access requested by a task labeled "*" is denied. >2. A read or execute access requested by a task labeled "^" > is permitted. >3. A read or execute access requested on an object labeled "_" > is permitted. >4. Any access requested on an object labeled "*" is permitted. >5. Any access requested by a task on an object with the same > label is permitted. >6. Any access requested that is explicitly defined in the loaded > rule set is permitted. >7. Any other access is denied. Some security systems that have the concept of "no default access" (task labeled "*") also allow access by those tasks but only if there is an explicit rule giving access to the task. IOW, rule 6 is applied before rule 1. In my experience this simplifies special cases where a task should only have access to a very small set of resources. I'm curious why smack goes the other way? - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler (on Sat, 11 Aug 2007 12:56:42 -0700 (PDT)) wrote:
>
>--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include "../../net/netlabel/netlabel_domainhash.h"
>>
>> can't you move this header to include/ instead?
>
>Paul Moore, the developer of netlabel, promised to work out
>the right solution for this with me at a future date. He
>doesn't want to move the header, and I respect that.
foo.c has
#include "netlabel_domainhash.h"
Makefile has CFLAGS_foo.o += -I$(srctree)/net/netlabel
I prefer to use -I $(srctree)/net/netlabel for readability but '-I '
breaks on SuSE builds for some reason that I cannot be bothered working
out. -I$(srctree)/net/netlabel works.
>> > + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
>> > + if (doip == NULL)
>> > + panic("smack: Failed to initialize cipso DOI.\n");
>> > + doip->map.std = NULL;
>> > +
>> > + ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
>> > + if (ndmp == NULL)
>> > + panic("smack: Failed to initialize cipso ndmp.\n");
>>
>>
>> is panic() really the right thing here? It's usually considered quite
>> rude ;)
>
>It's really early in start-up and if you're out of memory at that
>point you are not going very far into the future.
Not to mention that you might end up running with an insecure system.
Security must be failsafe.
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> writes:
>
> > Smack is the Simplified Mandatory Access Control Kernel.
>
> I like the simplified part.
>
> > +static int smk_get_access(smack_t sub, smack_t obj)
> > +{
> > + struct smk_list_entry *sp = smack_list;
> > +
> > + for (; sp != NULL; sp = sp->smk_next)
> > + if (sp->smk_rule.smk_subject == sub &&
> > + sp->smk_rule.smk_object == obj)
> > + return sp->smk_rule.smk_access;
>
> Do I miss something, or is there really no locking for the reader side
> of the list? That looks dangerous. Of course a global lock for readers
> would be likely a scaling disaster. You could use RCU.
Entries are never deleted, although they can be modified.
> Or if you assume rules are changed only very infrequently it might
> be more cache friendly to compile all the rules into a linear buffer
> and then just replace the whole buffer atomically with a RCU
> grace period on cahnges.
Individual entries can be modified without changing the whole
thing, but they shouldn't change often.
> It doesn't look like it would scale to larger numbers of rules though.
> Is that intended? Would caching of decisions fit into the design?
I put some thought into clever schemes for supporting large rule sets
well but decided to go ahead with the simplest possible mechanism
because I expect that in real deployments the number of rules will
be small. In fact, experiance says that virtually all access choices
will be covered either by the subject==object case or the subject can
read floor case. Cacheing, hashing, and 2D structures are all
possibilties that I would be happy to entertain as enhancements.
> Also in general code style would need some improvements;
> e.g. no externs in .c; no ../.. include hacks etc.
> You also seem weak on the Documentation front.
Yes, it is pretty sparse.
> Other than that it looks reasonably clean (haven't read all of it)
Thank you for your comments. I think the next version will be improved.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
> >> [SELinux...] which can do *all* of this, completely and without
> >> exceptions,
> >
> > That's quite a strong assertion.
>
> It is, but I stand by it. If anyone can point out some portion of
> this which *cannot* be implemented as SELinux policy I will humbly
> step completely out of this discussion.
Ok. I accept that you believe that this.
> >> but one does have to have complexity in order to handle everything
> >> from CD burning in X, to Apache daemons, to only allowing Top-
> >> Secret-level logins over the IPsec tunnel on the Top Secret
> >> network, etc.
> >
> > I do not agree with you. The MLS systems from the 1990's could do
> > all that (except the IPsec tunnel, the function of which was
> > preceeded by TSIG interfaces and protocols) without the complexity
> > required by SELinux policy.
>
> No, most/all of the MLS systems from the 1990s did not integrate Bell-
> LaPadula, Type Enforcement, and Role-Based-Access-Control together.
Err, that wasn't the claim I was refuting. I was refuting the claim
that performing those actions required complexity. The claim I was
refering to said nothing about any of those features or anything about
their integration.
> In addition, none of the MLS systems from the 1990s had modifiable
> constraints the way SELinux does (for example I can modify the
> fundamental policy to allow a process whose domain has the
> "i_am_special" attribute to override the BLP model for certain target
> types in certain special situations, all depending on how I apply
> that attribute and those types).
That's fine, but hardly relevent to the fact that the 1990's systems
performed the list of functions.
> >> For example, this set of rules basically defines your described
> >> "read-vs-write-vs-exec" policy as best I can figure out:
> >>
> >> user uu roles rr;
> >>
> >> role rr types { star floor hat huh };
> >>
> >> define(`r',`
> >> allow $1 $2:file { read getattr };
> >> allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
> >> allow $1 $2:ipc { getattr read associate unix_read };
> >> ## List of more "read" allow rules for different types of
> >> objects... ##
> >> ')
> >
> > It would be instructive for those who are not well versed in the
> > nuances of SELinux policy if you actually spelled out the whole
> > thing, rather than using "## and more ##". Part of the point of
> > Smack is the makeup of the full list that would be required here.
>
> Well, yes, but how exactly do you define "read", "write", and
> "execute" for the full list of SELinux object classes found here:
> http://www.tresys.com/selinux/obj_perms_help.html
Smack is designed to treat objects as consistantly as is reasonable.
The list of object classes defined by SELinux is great for a system
designed to treat accesses with the highest possible granularity.
This is not a design goal for Smack.
> I was considering compiling the complete list, but such an exercise
> would take me at least an hour to do properly and which categories
> individual permissions should be placed in could be argued for
> weeks.
I will be happy to consider your arguement when you are willing
to present the complete argument.
> The SELinux reference policy doesn't even completely qualify
> all of those things with MLS restrictions, and they're the ones who
> got the hooks implemented originally.
That doesn't help your case any.
> Specifically, do you classify the bind() syscall as a "read" or a
> "write" operation.
Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global namespace.
No objects are involved, hence no accesses.
> How would you classify accept()?
I don't. Accept happens after a TCP connection has been established.
The access control is all mediated long before the accept'er finds
out about it.
> In order to
> support the full range of security controls that Linux has hooks for,
> you would need to identify a list of how to define "read", "write",
> and "execute" for every object-class in that massive list.
> Furthermore you would need to ensure that the definitions work for
> every process. From the variations between different portions of the
> SELinux ref policy, I contend that there is no single definition of
> "read", or "write" which works for all usages of a given object-class.
There certainly isn't in SELinux. I don't subscribe the the list
of SELinux object classes. We can argue a long time over whether a
socket is an object or not, and it won't help any real world application
one bit.
> >> And now to describe these rules:
> >>
> >>> Smack defines and uses these labels:
> >>> "*" - pronounced "star"
> >>> "_" - pronounced "floor"
> >>> "^" - pronounced "hat"
> >>> "?" - pronounced "huh"
> >>>
> >>> The access rules enforced by Smack are, in
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 11 2007 10:57, Casey Schaufler wrote:
> >
> >"*" - pronounced "star"
> wall
> >"_" - pronounced "floor"
> floor
> >"^" - pronounced "hat"
> roof
> >"?" - pronounced "huh"
> it's dark in here :)
It's almost worth considering the change for the joke. Almost.
> >+config SECURITY_SMACK
> >+bool "Simplified Mandatory Access Control Kernel Support"
> >+depends on NETLABEL && SECURITY_NETWORK
>
> Is this a hard dependency, or can this work without network sec labels?
Smack uses netlabel to communicate label information even locally.
Without this only processes running with the ambient label would
be able to use sockets.
> >+default n
> >+help
> >+ This selects the Simplified Mandatory Access Control Kernel.
> >+ SMACK is useful for sensitivity, integrity, and a variety
> >+ of other madatory security schemes.
> >+ If you are unsure how to answer this question, answer N.
>
> I smell broken tabs.
Yup. Fixed.
> >+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
> >-0700
> >@@ -0,0 +1,8 @@
> >+#
> >+# Makefile for the SMACK LSM
> >+#
> >+
> >+obj-$(CONFIG_SECURITY_SMACK) := smack.o
> >+
> >+smack-y := smack_lsm.o smack_access.o smackfs.o
>
> smack-objs :=
Added.
> >+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24
> >15:36:18.0
> -0700
> >@@ -0,0 +1,113 @@
> >+extern struct smk_list_entry *smack_list;
> >+
> >+static int smk_get_access(smack_t sub, smack_t obj)
> >+{
> >+struct smk_list_entry *sp = smack_list;
>
> proposes const struct. should be used elsewhere too.
I've hit a few places.
> >+if (sub == SMK_STAR)
>
> I just remember MechWarrior2 (game from Activison), where SMK stood for their
> movie format... it's also a nice abbreviation for Seamonkey (browser suite).
Err, yeah. Okay.
> >+if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
> >+return 0;
> >+
> >+if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
> >+return 0;
>
> Redundant parentheses, be gone.
Done.
> Never was it easier to say what ^ is called in your language :)
>
> if (sub == '^' && ...)
> return 0;
> if (obj == '_' && ...)
>
> >+/*
> >+ * The value that this adds is that everything after any
> >+ * character that's not allowed in a smack will be null
> >+ */
> >+smack_t smk_from_string(char *str)
> >+{
> >+smack_t smack = 0LL;
>
> "smack_t smack = 0;" is enough here.
Ok.
> >+char *cp;
> >+int i;
> >+
> >+for (cp = (char *), i = 0; i < sizeof(smack_t); str++,cp++,i++) {
>
> Whatever it tries to do, this is not endian-safe. Except if @str
> actually points to another smack_t. Yuck.
Small string stuck in a large integer. The only operation is
comparison. Big or little endian the string will come out right,
and that's what's important.
> >+if (*str <= ' ' || *str > '~')
> >+return smack;
> >+*cp = *str;
> >+}
> >+/*
> >+ * Too long.
> >+ */
> >+return SMK_INVALID;
> >+}
> >diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
> linux-2.6.22-base/security/smack/smackfs.c
> linux-2.6.22/security/smack/smackfs.c
> >--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31
> >16:00:00.0
> -0800
> >+++ linux-2.6.22/security/smack/smackfs.c2007-07-24 21:51:30.0
> -0700
>
> Can't securityfs and/or sysfs be used?
I have to look into that for the configuration values. I don't
think I can do it for the symlinks.
> >+enum smk_inos {
> >+SMK_ROOT_INO = 2,
> >+SMK_LOAD = 3, /* load policy */
> >+SMK_LINKS = 4, /* symlinks */
> >+SMK_CIPSO = 5, /* load label -> CIPSO mapping */
> >+SMK_DOI = 6, /* CIPSO DOI */
> >+SMK_DIRECT =7, /* CIPSO level indicating direct label */
> >+SMK_AMBIENT = 8, /* internet ambient label */
> >+SMK_NLTYPE =9, /* label scheme to use by default */
> >+SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
> >+};
>
> Generally, =s are aligned too.
It's pretty inconsistant, but that's what I prefer, too. I'll do it.
> >+static struct smk_cipso_entry smack_cipso_floor = {
> >+.smk_next = NULL,
> >+.smk_smack = SMK_FLOOR,
> >+.smk_level = 0,
> >+.smk_catset = 0LL,
> >+};
>
> const me.
This is the correct tinitial value, but could be changed.
> >+/*
> >+ * ' \n\0'
> >+ */
>
> I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
> uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
> are actually meant as a char[8]? (/me scrathces head)
Yes. "s == o" vs "strcmp(s,o) == 0".
> >+for (cp = result; slp != NULL; slp = slp->smk_next) {
> >+srp = >smk_rule;
> >+sprintf(cp, "%-8s %-8s",
> >+(char *)>smk_subject, (char
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler <[EMAIL PROTECTED]> writes:
> Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
> +static int smk_get_access(smack_t sub, smack_t obj)
> +{
> + struct smk_list_entry *sp = smack_list;
> +
> + for (; sp != NULL; sp = sp->smk_next)
> + if (sp->smk_rule.smk_subject == sub &&
> + sp->smk_rule.smk_object == obj)
> + return sp->smk_rule.smk_access;
Do I miss something, or is there really no locking for the reader side
of the list? That looks dangerous. Of course a global lock for readers
would be likely a scaling disaster. You could use RCU.
Or if you assume rules are changed only very infrequently it might
be more cache friendly to compile all the rules into a linear buffer
and then just replace the whole buffer atomically with a RCU
grace period on cahnges.
It doesn't look like it would scale to larger numbers of rules though.
Is that intended? Would caching of decisions fit into the design?
Also in general code style would need some improvements;
e.g. no externs in .c; no ../.. include hacks etc.
You also seem weak on the Documentation front.
Other than that it looks reasonably clean (haven't read all of it)
-Andi
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this which *cannot* be implemented as SELinux policy I will humbly
step completely out of this discussion.
but one does have to have complexity in order to handle everything
from CD burning in X, to Apache daemons, to only allowing Top-
Secret-level logins over the IPsec tunnel on the Top Secret
network, etc.
I do not agree with you. The MLS systems from the 1990's could do
all that (except the IPsec tunnel, the function of which was
preceeded by TSIG interfaces and protocols) without the complexity
required by SELinux policy.
No, most/all of the MLS systems from the 1990s did not integrate Bell-
LaPadula, Type Enforcement, and Role-Based-Access-Control together.
In addition, none of the MLS systems from the 1990s had modifiable
constraints the way SELinux does (for example I can modify the
fundamental policy to allow a process whose domain has the
"i_am_special" attribute to override the BLP model for certain target
types in certain special situations, all depending on how I apply
that attribute and those types).
For example, this set of rules basically defines your described
"read-vs-write-vs-exec" policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of
objects... ##
')
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using "## and more ##". Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define "read", "write", and
"execute" for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
I was considering compiling the complete list, but such an exercise
would take me at least an hour to do properly and which categories
individual permissions should be placed in could be argued for
weeks. The SELinux reference policy doesn't even completely qualify
all of those things with MLS restrictions, and they're the ones who
got the hooks implemented originally.
Specifically, do you classify the bind() syscall as a "read" or a
"write" operation. How would you classify accept()? In order to
support the full range of security controls that Linux has hooks for,
you would need to identify a list of how to define "read", "write",
and "execute" for every object-class in that massive list.
Furthermore you would need to ensure that the definitions work for
every process. From the variations between different portions of the
SELinux ref policy, I contend that there is no single definition of
"read", or "write" which works for all usages of a given object-class.
And now to describe these rules:
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
is permitted.
3. A read or execute access requested on an object labeled "_"
is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##
What would that look like?
The same kind of thing as the r, x, and w above, with occasional
"type my_type_t; role rr types my_type_t;" to declare a type before
use. If you wanted to add support for attributes which apply to
multiple types, you could put those after a comma after the "type
my_type_t" portion of the type declaration.
Smack rule sets can be easily defined that describe Bell
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time
of day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
> > Smack implements mandatory access control (MAC) using labels
> > attached to tasks and data containers, including files, SVIPC, and
> > other tasks. Smack is a kernel based scheme that requires an
> > absolute minimum of application support and a very small amount of
> > configuration data.
>
> For starters, we would appear to already have a very capable
> labelling system
I am not going to argue that SELinux is not a capable
labelling system. SELinux is a fine implementation of
of Type Enforcement.
> which can do *all* of this, completely and without
> exceptions,
That's quite a strong assertion.
> in a much more flexible way.
Indeed, SELinux provides tremendous flexibility.
> Admittedly it's more complicated,
Yes, it is.
> but one does have to have complexity in order to handle
> everything from CD burning in X, to Apache daemons, to only allowing
> Top-Secret-level logins over the IPsec tunnel on the Top Secret
> network, etc.
I do not agree with you. The MLS systems from the 1990's could do all
that (except the IPsec tunnel, the function of which was preceeded by
TSIG interfaces and protocols) without the complexity required by
SELinux policy.
> Do you see any particular reason this couldn't be
> implemented as a very *very* simplified SELinux wrapper?
I would be interested to see the attempt made, but I have no interest
in doing so myself. I think that some of the reasons will come out
as we progress through your examples.
> For
> example, this set of rules basically defines your described "read-vs-
> write-vs-exec" policy as best I can figure out:
>
> user uu roles rr;
>
> role rr types { star floor hat huh };
>
> define(`r',`
> allow $1 $2:file { read getattr };
> allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
> allow $1 $2:ipc { getattr read associate unix_read };
> ## List of more "read" allow rules for different types of objects... ##
> ')
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using "## and more ##". Part of the point of
Smack is the makeup of the full list that would be required here.
> define(`w',`
> allow $1 $2:file { ioctl write create setattr lock append unlink link
> rename swapon quotaon mounton };
> allow $1 $2:socket { ioctl write create setattr lock append bind
> connect listen accept setopt shutdown sendto send_msg name_bind };
> allow $1 $2:ipc { create destroy setattr write unix_write };
> ## List of more "write" allow rules for different types of objects... ##
> ')
Again, I suggest you present the complete list.
> define(`x',`
> allow $1 $2:file { execute };
> allow $1 $2:dir { search };
> ## List of more "execute" allow rules for different types of
> objects... ##
> ')
Here too.
> And now to describe these rules:
>
> > Smack defines and uses these labels:
> > "*" - pronounced "star"
> > "_" - pronounced "floor"
> > "^" - pronounced "hat"
> > "?" - pronounced "huh"
> >
> > The access rules enforced by Smack are, in order:
> >
> > 1. Any access requested by a task labeled "*" is denied.
> > 2. A read or execute access requested by a task labeled "^"
> >is permitted.
> > 3. A read or execute access requested on an object labeled "_"
> >is permitted.
> > 4. Any access requested on an object labeled "*" is permitted.
> > 5. Any access requested by a task on an object with the same
> >label is permitted.
> > 6. Any access requested that is explicitly defined in the loaded
> >rule set is permitted.
> > 7. Any other access is denied.
>
> ## These are calls to the above macros which plug in the necessary
> arguments
> r(hat, {*})
> x(hat, {*})
> r(~{star}, floor)
> x(~{star}, floor)
> r(~{star}, star)
> w(~{star}, star)
> x(~{star}, star)
> r(~{star}, self)
> w(~{star}, self)
> x(~{star}, self)
> ## Include your "loaded rule set" here ##
What would that look like?
> > Rules may be explicitly defined by writing subject,object,access
> > triples to /smack/load.
>
> Maybe worth a little utility to convert a file full of
> "subject,object,access" triples to an appropriate SELinux policy
> would be appropriate?
Maybe. It would at least be educational for comparisons by those
looking to choose between the schemes.
> > Smack rule sets can be easily defined that describe Bell
> > sensitivity, Biba integrity, and a variety of interesting
> > configurations. Smack rule sets can be modified on the fly to
> > accomodate changes in the operating environment or even the time of
> > day.
>
> SELinux can do this as well. It even includes support for
> conditional policy:
>
> bool foo_can_do_logging true;
> if (foo_can_do_logging) {
> allow foo_t foo_log_t:file { create read getattr append };
> }
You have to build the booleans into the policy in advance.
> The SELinux
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 10:57, Casey Schaufler wrote:
>
>"*" - pronounced "star"
wall
>"_" - pronounced "floor"
floor
>"^" - pronounced "hat"
roof
>"?" - pronounced "huh"
it's dark in here :)
>+config SECURITY_SMACK
>+ bool "Simplified Mandatory Access Control Kernel Support"
>+ depends on NETLABEL && SECURITY_NETWORK
Is this a hard dependency, or can this work without network sec labels?
>+ default n
>+ help
>+This selects the Simplified Mandatory Access Control Kernel.
>+SMACK is useful for sensitivity, integrity, and a variety
>+ of other madatory security schemes.
>+If you are unsure how to answer this question, answer N.
I smell broken tabs.
>+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
>-0700
>@@ -0,0 +1,8 @@
>+#
>+# Makefile for the SMACK LSM
>+#
>+
>+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>+
>+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
>+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0
>-0700
>@@ -0,0 +1,113 @@
>+extern struct smk_list_entry *smack_list;
>+
>+static int smk_get_access(smack_t sub, smack_t obj)
>+{
>+ struct smk_list_entry *sp = smack_list;
proposes const struct. should be used elsewhere too.
>+ if (sub == SMK_STAR)
I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).
>+ if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
>+ return 0;
>+
>+ if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
>+ return 0;
Redundant parentheses, be gone.
Never was it easier to say what ^ is called in your language :)
if (sub == '^' && ...)
return 0;
if (obj == '_' && ...)
>+/*
>+ * The value that this adds is that everything after any
>+ * character that's not allowed in a smack will be null
>+ */
>+smack_t smk_from_string(char *str)
>+{
>+ smack_t smack = 0LL;
"smack_t smack = 0;" is enough here.
>+ char *cp;
>+ int i;
>+
>+ for (cp = (char *), i = 0; i < sizeof(smack_t); str++,cp++,i++) {
Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.
>+ if (*str <= ' ' || *str > '~')
>+ return smack;
>+ *cp = *str;
>+ }
>+ /*
>+ * Too long.
>+ */
>+ return SMK_INVALID;
>+}
>diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
>linux-2.6.22-base/security/smack/smackfs.c
>linux-2.6.22/security/smack/smackfs.c
>--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.0
>-0800
>+++ linux-2.6.22/security/smack/smackfs.c 2007-07-24 21:51:30.0
>-0700
Can't securityfs and/or sysfs be used?
>+enum smk_inos {
>+ SMK_ROOT_INO = 2,
>+ SMK_LOAD = 3, /* load policy */
>+ SMK_LINKS = 4, /* symlinks */
>+ SMK_CIPSO = 5, /* load label -> CIPSO mapping */
>+ SMK_DOI = 6, /* CIPSO DOI */
>+ SMK_DIRECT =7, /* CIPSO level indicating direct label */
>+ SMK_AMBIENT = 8, /* internet ambient label */
>+ SMK_NLTYPE =9, /* label scheme to use by default */
>+ SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
>+};
Generally, =s are aligned too.
>+static struct smk_cipso_entry smack_cipso_floor = {
>+.smk_next = NULL,
>+.smk_smack = SMK_FLOOR,
>+.smk_level = 0,
>+.smk_catset = 0LL,
>+};
const me.
>+/*
>+ * ' \n\0'
>+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
>+ for (cp = result; slp != NULL; slp = slp->smk_next) {
>+ srp = >smk_rule;
>+ sprintf(cp, "%-8s %-8s",
>+ (char *)>smk_subject, (char *)>smk_object);
I like (const char *).
>+ printk("%s:%d bad scan\n",
>+ __FUNCTION__, __LINE__);
__FUNCTION__ is a GNU extension, C99 uses __func__.
Not sure what they've got for __LINE__.
>+ if (strchr(modestr, 'r') || strchr(modestr, 'R'))
>+ rule.smk_access |= MAY_READ;
>+ if (strchr(modestr, 'w') || strchr(modestr, 'W'))
>+ rule.smk_access |= MAY_WRITE;
>+ if (strchr(modestr, 'x') || strchr(modestr, 'X'))
>+ rule.smk_access |= MAY_EXEC;
>+ if (strchr(modestr, 'a') || strchr(modestr, 'A'))
>+ rule.smk_access |= MAY_APPEND;
There's strpbrk() available for you.
>+static char *smk_digit(char *cp)
>+{
>+ for (; *cp != '\0'; cp++)
>+ if (*cp >= '0' && *cp <= '9')
>+ return cp;
>+
>+ return NULL;
>+}
strpbrk
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > +extern struct smk_list_entry *smack_list;
>
> any reason to invent your own list rather than just using list.h?
The list.h mechanisms are fine, but heavier than I require.
I'm willing to give in on it, but I don't see an advantage.
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "../../net/netlabel/netlabel_domainhash.h"
>
> can't you move this header to include/ instead?
Paul Moore, the developer of netlabel, promised to work out
the right solution for this with me at a future date. He
doesn't want to move the header, and I respect that.
> > +
> > +static struct file_operations smk_load_ops = {
> > + .read = smk_read_load,
> > + .write = smk_write_load,
> > +};
>
> make that a const please
Will do.
> > +
> > + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
> > + if (doip == NULL)
> > + panic("smack: Failed to initialize cipso DOI.\n");
> > + doip->map.std = NULL;
> > +
> > + ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
> > + if (ndmp == NULL)
> > + panic("smack: Failed to initialize cipso ndmp.\n");
>
>
> is panic() really the right thing here? It's usually considered quite
> rude ;)
It's really early in start-up and if you're out of memory at that
point you are not going very far into the future.
> > +static struct file_operations smk_cipso_ops = {
> > + .read = smk_read_cipso,
> > + .write = smk_write_cipso,
> > +};
>
> another candidate for const
Will do that, too.
> > +static void *smackfs_follow_link(struct dentry *dentry, struct nameidata
> *nd)
> > +{
>
>
> this one deserves a comment; are you implementing magic symlinks here?
Yup.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
absolute minimum of application support and a very small amount of
configuration data.
For starters, we would appear to already have a very capable
labelling system which can do *all* of this, completely and without
exceptions, in a much more flexible way. Admittedly it's more
complicated, but one does have to have complexity in order to handle
everything from CD burning in X, to Apache daemons, to only allowing
Top-Secret-level logins over the IPsec tunnel on the Top Secret
network, etc. Do you see any particular reason this couldn't be
implemented as a very *very* simplified SELinux wrapper? For
example, this set of rules basically defines your described "read-vs-
write-vs-exec" policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of objects... ##
')
define(`w',`
allow $1 $2:file { ioctl write create setattr lock append unlink link
rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind
connect listen accept setopt shutdown sendto send_msg name_bind };
allow $1 $2:ipc { create destroy setattr write unix_write };
## List of more "write" allow rules for different types of objects... ##
')
define(`x',`
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more "execute" allow rules for different types of
objects... ##
')
And now to describe these rules:
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
is permitted.
3. A read or execute access requested on an object labeled "_"
is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##
Rules may be explicitly defined by writing subject,object,access
triples to /smack/load.
Maybe worth a little utility to convert a file full of
"subject,object,access" triples to an appropriate SELinux policy
would be appropriate?
Smack rule sets can be easily defined that describe Bell
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time of
day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
The SELinux tools also have support for policy modules, so you can
extend the policy without modifying the base system. Plus the stuff
has been very heavily tested and even supports X (as soon as the beta
X code gets improved and merged in the upstream X.org codebase).
Some practical use cases:
Hierarchical levels. The less common of the two usual uses for MLS
systems is to define hierarchical levels, often unclassified,
confidential, secret, and so on. To set up smack to support this,
these rules could be defined:
CUnclass rx
SC rx
SUnclass rx
TS S rx
TS C rx
TS Unclass rx
A TS process can read S, C, and Unclass data, but cannot write it.
An S process can read C and Unclass. Note that specifying that
TS can read S and S can read C does not imply TS can read C, it
has to be explicitly stated.
The big problem here is the duplication. Say you have a locked-down
Apache configuration and you want to run 2 apache processes, one at
Secret and one at Top-Secret. Under your model you have to copy-
paste the policy and make sure to apply fixes/changes to both
places. Under SELinux, you can have processes as:
system_u:system_r:httpd_t:Secret:UFOSightings,AlienDissection
system_u:system_r:httpd_t:TopSecret:NukeTests
They can only read and write objects for which multiple conditions
are true: First, the object must
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
> +extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../../net/netlabel/netlabel_domainhash.h"
can't you move this header to include/ instead?
> +
> +static struct file_operations smk_load_ops = {
> + .read = smk_read_load,
> + .write = smk_write_load,
> +};
make that a const please
> +
> + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
> + if (doip == NULL)
> + panic("smack: Failed to initialize cipso DOI.\n");
> + doip->map.std = NULL;
> +
> + ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
> + if (ndmp == NULL)
> + panic("smack: Failed to initialize cipso ndmp.\n");
is panic() really the right thing here? It's usually considered quite
rude ;)
> +static struct file_operations smk_cipso_ops = {
> + .read = smk_read_cipso,
> + .write = smk_write_cipso,
> +};
another candidate for const
> +static void *smackfs_follow_link(struct dentry *dentry, struct nameidata *nd)
> +{
this one deserves a comment; are you implementing magic symlinks here?
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
+extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
+
+#include linux/kernel.h
+#include linux/vmalloc.h
+#include linux/security.h
+#include linux/mutex.h
+#include net/netlabel.h
+#include ../../net/netlabel/netlabel_domainhash.h
can't you move this header to include/ instead?
+
+static struct file_operations smk_load_ops = {
+ .read = smk_read_load,
+ .write = smk_write_load,
+};
make that a const please
+
+ doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
+ if (doip == NULL)
+ panic(smack: Failed to initialize cipso DOI.\n);
+ doip-map.std = NULL;
+
+ ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
+ if (ndmp == NULL)
+ panic(smack: Failed to initialize cipso ndmp.\n);
is panic() really the right thing here? It's usually considered quite
rude ;)
+static struct file_operations smk_cipso_ops = {
+ .read = smk_read_cipso,
+ .write = smk_write_cipso,
+};
another candidate for const
+static void *smackfs_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
this one deserves a comment; are you implementing magic symlinks here?
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
absolute minimum of application support and a very small amount of
configuration data.
For starters, we would appear to already have a very capable
labelling system which can do *all* of this, completely and without
exceptions, in a much more flexible way. Admittedly it's more
complicated, but one does have to have complexity in order to handle
everything from CD burning in X, to Apache daemons, to only allowing
Top-Secret-level logins over the IPsec tunnel on the Top Secret
network, etc. Do you see any particular reason this couldn't be
implemented as a very *very* simplified SELinux wrapper? For
example, this set of rules basically defines your described read-vs-
write-vs-exec policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more read allow rules for different types of objects... ##
')
define(`w',`
allow $1 $2:file { ioctl write create setattr lock append unlink link
rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind
connect listen accept setopt shutdown sendto send_msg name_bind };
allow $1 $2:ipc { create destroy setattr write unix_write };
## List of more write allow rules for different types of objects... ##
')
define(`x',`
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more execute allow rules for different types of
objects... ##
')
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^
is permitted.
3. A read or execute access requested on an object labeled _
is permitted.
4. Any access requested on an object labeled * is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your loaded rule set here ##
Rules may be explicitly defined by writing subject,object,access
triples to /smack/load.
Maybe worth a little utility to convert a file full of
subject,object,access triples to an appropriate SELinux policy
would be appropriate?
Smack rule sets can be easily defined that describe BellLaPadula
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time of
day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
The SELinux tools also have support for policy modules, so you can
extend the policy without modifying the base system. Plus the stuff
has been very heavily tested and even supports X (as soon as the beta
X code gets improved and merged in the upstream X.org codebase).
Some practical use cases:
Hierarchical levels. The less common of the two usual uses for MLS
systems is to define hierarchical levels, often unclassified,
confidential, secret, and so on. To set up smack to support this,
these rules could be defined:
CUnclass rx
SC rx
SUnclass rx
TS S rx
TS C rx
TS Unclass rx
A TS process can read S, C, and Unclass data, but cannot write it.
An S process can read C and Unclass. Note that specifying that
TS can read S and S can read C does not imply TS can read C, it
has to be explicitly stated.
The big problem here is the duplication. Say you have a locked-down
Apache configuration and you want to run 2 apache processes, one at
Secret and one at Top-Secret. Under your model you have to copy-
paste the policy and make sure to apply fixes/changes to both
places. Under SELinux, you can have processes as:
system_u:system_r:httpd_t:Secret:UFOSightings,AlienDissection
system_u:system_r:httpd_t:TopSecret:NukeTests
They can only read and write objects for which multiple conditions
are true: First, the object must match the Bell-Padula model
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Arjan van de Ven [EMAIL PROTECTED] wrote:
+extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
The list.h mechanisms are fine, but heavier than I require.
I'm willing to give in on it, but I don't see an advantage.
+
+#include linux/kernel.h
+#include linux/vmalloc.h
+#include linux/security.h
+#include linux/mutex.h
+#include net/netlabel.h
+#include ../../net/netlabel/netlabel_domainhash.h
can't you move this header to include/ instead?
Paul Moore, the developer of netlabel, promised to work out
the right solution for this with me at a future date. He
doesn't want to move the header, and I respect that.
+
+static struct file_operations smk_load_ops = {
+ .read = smk_read_load,
+ .write = smk_write_load,
+};
make that a const please
Will do.
+
+ doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
+ if (doip == NULL)
+ panic(smack: Failed to initialize cipso DOI.\n);
+ doip-map.std = NULL;
+
+ ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL);
+ if (ndmp == NULL)
+ panic(smack: Failed to initialize cipso ndmp.\n);
is panic() really the right thing here? It's usually considered quite
rude ;)
It's really early in start-up and if you're out of memory at that
point you are not going very far into the future.
+static struct file_operations smk_cipso_ops = {
+ .read = smk_read_cipso,
+ .write = smk_write_cipso,
+};
another candidate for const
Will do that, too.
+static void *smackfs_follow_link(struct dentry *dentry, struct nameidata
*nd)
+{
this one deserves a comment; are you implementing magic symlinks here?
Yup.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
+config SECURITY_SMACK
+ bool Simplified Mandatory Access Control Kernel Support
+ depends on NETLABEL SECURITY_NETWORK
Is this a hard dependency, or can this work without network sec labels?
+ default n
+ help
+This selects the Simplified Mandatory Access Control Kernel.
+SMACK is useful for sensitivity, integrity, and a variety
+ of other madatory security schemes.
+If you are unsure how to answer this question, answer N.
I smell broken tabs.
+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
-0700
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0
-0700
@@ -0,0 +1,113 @@
+extern struct smk_list_entry *smack_list;
+
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
proposes const struct. should be used elsewhere too.
+ if (sub == SMK_STAR)
I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).
+ if (sub == SMK_HAT ((request MAY_ANYREAD) == request))
+ return 0;
+
+ if (obj == SMK_FLOOR ((request MAY_ANYREAD) == request))
+ return 0;
Redundant parentheses, be gone.
Never was it easier to say what ^ is called in your language :)
if (sub == '^' ...)
return 0;
if (obj == '_' ...)
+/*
+ * The value that this adds is that everything after any
+ * character that's not allowed in a smack will be null
+ */
+smack_t smk_from_string(char *str)
+{
+ smack_t smack = 0LL;
smack_t smack = 0; is enough here.
+ char *cp;
+ int i;
+
+ for (cp = (char *)smack, i = 0; i sizeof(smack_t); str++,cp++,i++) {
Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.
+ if (*str = ' ' || *str '~')
+ return smack;
+ *cp = *str;
+ }
+ /*
+ * Too long.
+ */
+ return SMK_INVALID;
+}
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/smackfs.c
linux-2.6.22/security/smack/smackfs.c
--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.22/security/smack/smackfs.c 2007-07-24 21:51:30.0
-0700
Can't securityfs and/or sysfs be used?
+enum smk_inos {
+ SMK_ROOT_INO = 2,
+ SMK_LOAD = 3, /* load policy */
+ SMK_LINKS = 4, /* symlinks */
+ SMK_CIPSO = 5, /* load label - CIPSO mapping */
+ SMK_DOI = 6, /* CIPSO DOI */
+ SMK_DIRECT =7, /* CIPSO level indicating direct label */
+ SMK_AMBIENT = 8, /* internet ambient label */
+ SMK_NLTYPE =9, /* label scheme to use by default */
+ SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
+};
Generally, =s are aligned too.
+static struct smk_cipso_entry smack_cipso_floor = {
+.smk_next = NULL,
+.smk_smack = SMK_FLOOR,
+.smk_level = 0,
+.smk_catset = 0LL,
+};
const me.
+/*
+ * ' \n\0'
+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
+ for (cp = result; slp != NULL; slp = slp-smk_next) {
+ srp = slp-smk_rule;
+ sprintf(cp, %-8s %-8s,
+ (char *)srp-smk_subject, (char *)srp-smk_object);
I like (const char *).
+ printk(%s:%d bad scan\n,
+ __FUNCTION__, __LINE__);
__FUNCTION__ is a GNU extension, C99 uses __func__.
Not sure what they've got for __LINE__.
+ if (strchr(modestr, 'r') || strchr(modestr, 'R'))
+ rule.smk_access |= MAY_READ;
+ if (strchr(modestr, 'w') || strchr(modestr, 'W'))
+ rule.smk_access |= MAY_WRITE;
+ if (strchr(modestr, 'x') || strchr(modestr, 'X'))
+ rule.smk_access |= MAY_EXEC;
+ if (strchr(modestr, 'a') || strchr(modestr, 'A'))
+ rule.smk_access |= MAY_APPEND;
There's strpbrk() available for you.
+static char *smk_digit(char *cp)
+{
+ for (; *cp != '\0'; cp++)
+ if (*cp = '0' *cp = '9')
+ return cp;
+
+ return NULL;
+}
strpbrk again.
+static int smk_cipso_doied;
+static int smk_cipso_written;
Votes for unsigned int if it {can never be, is not intended to be}
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
absolute minimum of application support and a very small amount of
configuration data.
For starters, we would appear to already have a very capable
labelling system
I am not going to argue that SELinux is not a capable
labelling system. SELinux is a fine implementation of
of Type Enforcement.
which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
in a much more flexible way.
Indeed, SELinux provides tremendous flexibility.
Admittedly it's more complicated,
Yes, it is.
but one does have to have complexity in order to handle
everything from CD burning in X, to Apache daemons, to only allowing
Top-Secret-level logins over the IPsec tunnel on the Top Secret
network, etc.
I do not agree with you. The MLS systems from the 1990's could do all
that (except the IPsec tunnel, the function of which was preceeded by
TSIG interfaces and protocols) without the complexity required by
SELinux policy.
Do you see any particular reason this couldn't be
implemented as a very *very* simplified SELinux wrapper?
I would be interested to see the attempt made, but I have no interest
in doing so myself. I think that some of the reasons will come out
as we progress through your examples.
For
example, this set of rules basically defines your described read-vs-
write-vs-exec policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more read allow rules for different types of objects... ##
')
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using ## and more ##. Part of the point of
Smack is the makeup of the full list that would be required here.
define(`w',`
allow $1 $2:file { ioctl write create setattr lock append unlink link
rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind
connect listen accept setopt shutdown sendto send_msg name_bind };
allow $1 $2:ipc { create destroy setattr write unix_write };
## List of more write allow rules for different types of objects... ##
')
Again, I suggest you present the complete list.
define(`x',`
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more execute allow rules for different types of
objects... ##
')
Here too.
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^
is permitted.
3. A read or execute access requested on an object labeled _
is permitted.
4. Any access requested on an object labeled * is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your loaded rule set here ##
What would that look like?
Rules may be explicitly defined by writing subject,object,access
triples to /smack/load.
Maybe worth a little utility to convert a file full of
subject,object,access triples to an appropriate SELinux policy
would be appropriate?
Maybe. It would at least be educational for comparisons by those
looking to choose between the schemes.
Smack rule sets can be easily defined that describe BellLaPadula
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time of
day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
You have to build the booleans into the policy in advance.
The SELinux tools also have support for policy modules, so you can
extend the policy without modifying the base system.
And that's a good thing, but you still have to
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this which *cannot* be implemented as SELinux policy I will humbly
step completely out of this discussion.
but one does have to have complexity in order to handle everything
from CD burning in X, to Apache daemons, to only allowing Top-
Secret-level logins over the IPsec tunnel on the Top Secret
network, etc.
I do not agree with you. The MLS systems from the 1990's could do
all that (except the IPsec tunnel, the function of which was
preceeded by TSIG interfaces and protocols) without the complexity
required by SELinux policy.
No, most/all of the MLS systems from the 1990s did not integrate Bell-
LaPadula, Type Enforcement, and Role-Based-Access-Control together.
In addition, none of the MLS systems from the 1990s had modifiable
constraints the way SELinux does (for example I can modify the
fundamental policy to allow a process whose domain has the
i_am_special attribute to override the BLP model for certain target
types in certain special situations, all depending on how I apply
that attribute and those types).
For example, this set of rules basically defines your described
read-vs-write-vs-exec policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more read allow rules for different types of
objects... ##
')
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using ## and more ##. Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define read, write, and
execute for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
I was considering compiling the complete list, but such an exercise
would take me at least an hour to do properly and which categories
individual permissions should be placed in could be argued for
weeks. The SELinux reference policy doesn't even completely qualify
all of those things with MLS restrictions, and they're the ones who
got the hooks implemented originally.
Specifically, do you classify the bind() syscall as a read or a
write operation. How would you classify accept()? In order to
support the full range of security controls that Linux has hooks for,
you would need to identify a list of how to define read, write,
and execute for every object-class in that massive list.
Furthermore you would need to ensure that the definitions work for
every process. From the variations between different portions of the
SELinux ref policy, I contend that there is no single definition of
read, or write which works for all usages of a given object-class.
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^
is permitted.
3. A read or execute access requested on an object labeled _
is permitted.
4. Any access requested on an object labeled * is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your loaded rule set here ##
What would that look like?
The same kind of thing as the r, x, and w above, with occasional
type my_type_t; role rr types my_type_t; to declare a type before
use. If you wanted to add support for attributes which apply to
multiple types, you could put those after a comma after the type
my_type_t portion of the type declaration.
Smack rule sets can be easily defined that describe BellLaPadula
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time
of day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
You have to build the booleans into the
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler [EMAIL PROTECTED] writes:
Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
+
+ for (; sp != NULL; sp = sp-smk_next)
+ if (sp-smk_rule.smk_subject == sub
+ sp-smk_rule.smk_object == obj)
+ return sp-smk_rule.smk_access;
Do I miss something, or is there really no locking for the reader side
of the list? That looks dangerous. Of course a global lock for readers
would be likely a scaling disaster. You could use RCU.
Or if you assume rules are changed only very infrequently it might
be more cache friendly to compile all the rules into a linear buffer
and then just replace the whole buffer atomically with a RCU
grace period on cahnges.
It doesn't look like it would scale to larger numbers of rules though.
Is that intended? Would caching of decisions fit into the design?
Also in general code style would need some improvements;
e.g. no externs in .c; no ../.. include hacks etc.
You also seem weak on the Documentation front.
Other than that it looks reasonably clean (haven't read all of it)
-Andi
-
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
It's almost worth considering the change for the joke. Almost.
+config SECURITY_SMACK
+bool Simplified Mandatory Access Control Kernel Support
+depends on NETLABEL SECURITY_NETWORK
Is this a hard dependency, or can this work without network sec labels?
Smack uses netlabel to communicate label information even locally.
Without this only processes running with the ambient label would
be able to use sockets.
+default n
+help
+ This selects the Simplified Mandatory Access Control Kernel.
+ SMACK is useful for sensitivity, integrity, and a variety
+ of other madatory security schemes.
+ If you are unsure how to answer this question, answer N.
I smell broken tabs.
Yup. Fixed.
+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
-0700
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
Added.
+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24
15:36:18.0
-0700
@@ -0,0 +1,113 @@
+extern struct smk_list_entry *smack_list;
+
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+struct smk_list_entry *sp = smack_list;
proposes const struct. should be used elsewhere too.
I've hit a few places.
+if (sub == SMK_STAR)
I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).
Err, yeah. Okay.
+if (sub == SMK_HAT ((request MAY_ANYREAD) == request))
+return 0;
+
+if (obj == SMK_FLOOR ((request MAY_ANYREAD) == request))
+return 0;
Redundant parentheses, be gone.
Done.
Never was it easier to say what ^ is called in your language :)
if (sub == '^' ...)
return 0;
if (obj == '_' ...)
+/*
+ * The value that this adds is that everything after any
+ * character that's not allowed in a smack will be null
+ */
+smack_t smk_from_string(char *str)
+{
+smack_t smack = 0LL;
smack_t smack = 0; is enough here.
Ok.
+char *cp;
+int i;
+
+for (cp = (char *)smack, i = 0; i sizeof(smack_t); str++,cp++,i++) {
Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.
Small string stuck in a large integer. The only operation is
comparison. Big or little endian the string will come out right,
and that's what's important.
+if (*str = ' ' || *str '~')
+return smack;
+*cp = *str;
+}
+/*
+ * Too long.
+ */
+return SMK_INVALID;
+}
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/smackfs.c
linux-2.6.22/security/smack/smackfs.c
--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31
16:00:00.0
-0800
+++ linux-2.6.22/security/smack/smackfs.c2007-07-24 21:51:30.0
-0700
Can't securityfs and/or sysfs be used?
I have to look into that for the configuration values. I don't
think I can do it for the symlinks.
+enum smk_inos {
+SMK_ROOT_INO = 2,
+SMK_LOAD = 3, /* load policy */
+SMK_LINKS = 4, /* symlinks */
+SMK_CIPSO = 5, /* load label - CIPSO mapping */
+SMK_DOI = 6, /* CIPSO DOI */
+SMK_DIRECT =7, /* CIPSO level indicating direct label */
+SMK_AMBIENT = 8, /* internet ambient label */
+SMK_NLTYPE =9, /* label scheme to use by default */
+SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
+};
Generally, =s are aligned too.
It's pretty inconsistant, but that's what I prefer, too. I'll do it.
+static struct smk_cipso_entry smack_cipso_floor = {
+.smk_next = NULL,
+.smk_smack = SMK_FLOOR,
+.smk_level = 0,
+.smk_catset = 0LL,
+};
const me.
This is the correct tinitial value, but could be changed.
+/*
+ * ' \n\0'
+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
Yes. s == o vs strcmp(s,o) == 0.
+for (cp = result; slp != NULL; slp = slp-smk_next) {
+srp = slp-smk_rule;
+sprintf(cp, %-8s %-8s,
+(char *)srp-smk_subject, (char *)srp-smk_object);
I like (const char *).
+printk(%s:%d bad scan\n,
+__FUNCTION__, __LINE__);
__FUNCTION__ is a GNU extension, C99 uses __func__.
Changed, although it's used extensively elsewhere.
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this which *cannot* be implemented as SELinux policy I will humbly
step completely out of this discussion.
Ok. I accept that you believe that this.
but one does have to have complexity in order to handle everything
from CD burning in X, to Apache daemons, to only allowing Top-
Secret-level logins over the IPsec tunnel on the Top Secret
network, etc.
I do not agree with you. The MLS systems from the 1990's could do
all that (except the IPsec tunnel, the function of which was
preceeded by TSIG interfaces and protocols) without the complexity
required by SELinux policy.
No, most/all of the MLS systems from the 1990s did not integrate Bell-
LaPadula, Type Enforcement, and Role-Based-Access-Control together.
Err, that wasn't the claim I was refuting. I was refuting the claim
that performing those actions required complexity. The claim I was
refering to said nothing about any of those features or anything about
their integration.
In addition, none of the MLS systems from the 1990s had modifiable
constraints the way SELinux does (for example I can modify the
fundamental policy to allow a process whose domain has the
i_am_special attribute to override the BLP model for certain target
types in certain special situations, all depending on how I apply
that attribute and those types).
That's fine, but hardly relevent to the fact that the 1990's systems
performed the list of functions.
For example, this set of rules basically defines your described
read-vs-write-vs-exec policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more read allow rules for different types of
objects... ##
')
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using ## and more ##. Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define read, write, and
execute for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
Smack is designed to treat objects as consistantly as is reasonable.
The list of object classes defined by SELinux is great for a system
designed to treat accesses with the highest possible granularity.
This is not a design goal for Smack.
I was considering compiling the complete list, but such an exercise
would take me at least an hour to do properly and which categories
individual permissions should be placed in could be argued for
weeks.
I will be happy to consider your arguement when you are willing
to present the complete argument.
The SELinux reference policy doesn't even completely qualify
all of those things with MLS restrictions, and they're the ones who
got the hooks implemented originally.
That doesn't help your case any.
Specifically, do you classify the bind() syscall as a read or a
write operation.
Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global namespace.
No objects are involved, hence no accesses.
How would you classify accept()?
I don't. Accept happens after a TCP connection has been established.
The access control is all mediated long before the accept'er finds
out about it.
In order to
support the full range of security controls that Linux has hooks for,
you would need to identify a list of how to define read, write,
and execute for every object-class in that massive list.
Furthermore you would need to ensure that the definitions work for
every process. From the variations between different portions of the
SELinux ref policy, I contend that there is no single definition of
read, or write which works for all usages of a given object-class.
There certainly isn't in SELinux. I don't subscribe the the list
of SELinux object classes. We can argue a long time over whether a
socket is an object or not, and it won't help any real world application
one bit.
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^
is permitted.
3. A read or execute access requested on an object
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] writes:
Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
+
+ for (; sp != NULL; sp = sp-smk_next)
+ if (sp-smk_rule.smk_subject == sub
+ sp-smk_rule.smk_object == obj)
+ return sp-smk_rule.smk_access;
Do I miss something, or is there really no locking for the reader side
of the list? That looks dangerous. Of course a global lock for readers
would be likely a scaling disaster. You could use RCU.
Entries are never deleted, although they can be modified.
Or if you assume rules are changed only very infrequently it might
be more cache friendly to compile all the rules into a linear buffer
and then just replace the whole buffer atomically with a RCU
grace period on cahnges.
Individual entries can be modified without changing the whole
thing, but they shouldn't change often.
It doesn't look like it would scale to larger numbers of rules though.
Is that intended? Would caching of decisions fit into the design?
I put some thought into clever schemes for supporting large rule sets
well but decided to go ahead with the simplest possible mechanism
because I expect that in real deployments the number of rules will
be small. In fact, experiance says that virtually all access choices
will be covered either by the subject==object case or the subject can
read floor case. Cacheing, hashing, and 2D structures are all
possibilties that I would be happy to entertain as enhancements.
Also in general code style would need some improvements;
e.g. no externs in .c; no ../.. include hacks etc.
You also seem weak on the Documentation front.
Yes, it is pretty sparse.
Other than that it looks reasonably clean (haven't read all of it)
Thank you for your comments. I think the next version will be improved.
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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler (on Sat, 11 Aug 2007 12:56:42 -0700 (PDT)) wrote: --- Arjan van de Ven [EMAIL PROTECTED] wrote: +#include linux/kernel.h +#include linux/vmalloc.h +#include linux/security.h +#include linux/mutex.h +#include net/netlabel.h +#include ../../net/netlabel/netlabel_domainhash.h can't you move this header to include/ instead? Paul Moore, the developer of netlabel, promised to work out the right solution for this with me at a future date. He doesn't want to move the header, and I respect that. foo.c has #include netlabel_domainhash.h Makefile has CFLAGS_foo.o += -I$(srctree)/net/netlabel I prefer to use -I $(srctree)/net/netlabel for readability but '-I ' breaks on SuSE builds for some reason that I cannot be bothered working out. -I$(srctree)/net/netlabel works. + doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL); + if (doip == NULL) + panic(smack: Failed to initialize cipso DOI.\n); + doip-map.std = NULL; + + ndmp = kmalloc(sizeof(struct netlbl_dom_map), GFP_KERNEL); + if (ndmp == NULL) + panic(smack: Failed to initialize cipso ndmp.\n); is panic() really the right thing here? It's usually considered quite rude ;) It's really early in start-up and if you're out of memory at that point you are not going very far into the future. Not to mention that you might end up running with an insecure system. Security must be failsafe. - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote: Smack is the Simplified Mandatory Access Control Kernel. [snip] Smack defines and uses these labels: * - pronounced star _ - pronounced floor ^ - pronounced hat ? - pronounced huh The access rules enforced by Smack are, in order: 1. Any access requested by a task labeled * is denied. 2. A read or execute access requested by a task labeled ^ is permitted. 3. A read or execute access requested on an object labeled _ is permitted. 4. Any access requested on an object labeled * is permitted. 5. Any access requested by a task on an object with the same label is permitted. 6. Any access requested that is explicitly defined in the loaded rule set is permitted. 7. Any other access is denied. Some security systems that have the concept of no default access (task labeled *) also allow access by those tasks but only if there is an explicit rule giving access to the task. IOW, rule 6 is applied before rule 1. In my experience this simplifies special cases where a task should only have access to a very small set of resources. I'm curious why smack goes the other way? - 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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the
nuances of SELinux policy if you actually spelled out the whole
thing, rather than using ## and more ##. Part of the point of
Smack is the makeup of the full list that would be required here.
Well, yes, but how exactly do you define read, write, and
execute for the full list of SELinux object classes found here:
http://www.tresys.com/selinux/obj_perms_help.html
Smack is designed to treat objects as consistantly as is
reasonable. The list of object classes defined by SELinux is great
for a system designed to treat accesses with the highest possible
granularity. This is not a design goal for Smack.
I was considering compiling the complete list, but such an
exercise would take me at least an hour to do properly and which
categories individual permissions should be placed in could be
argued for weeks.
I will be happy to consider your arguement when you are willing to
present the complete argument.
Here's my complete argument:
Regardless of how you categorize read, write, execute, and
doesnt-need-protection in your policy language, I can write an
SELinux policy and a list of labels which expresses that policy.
Moreover, without too much work I can probably write a Perl script to
do it for you. On the other hand I can only do that if you tell me
exactly how you want to categorize those things, though. In my
personal opinion they cannot be reasonably categorized without
breaking all sorts of tools or leaving gaping holes; precisely the
reason that SELinux uses such a fine-grained list.
Specifically, do you classify the bind() syscall as a read or a
write operation.
Neither. Bind attaches a name (port number) to a socket (which is a
data structure that is part of your process) from a global
namespace. No objects are involved, hence no accesses.
So bind() doesn't present a security hole at all and any program
may bind to any port? Sounds fun! I'm sure lots of crackers would
love to get ahold of an account on such a web-server; what havoc they
could wreak! Even the 1024 restriction doesn't sufficiently limit
things these days, as many critical services use ports =1024.
And now to describe these rules:
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled * is denied.
2. A read or execute access requested by a task labeled ^ is
permitted.
3. A read or execute access requested on an object labeled _
is permitted.
4. Any access requested on an object labeled * is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the
loaded rule set is permitted.
7. Any other access is denied.
## These are calls to the above macros which plug in the
necessary arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your loaded rule set here ##
What would that look like?
The same kind of thing as the r, x, and w above, with occasional
type my_type_t; role rr types my_type_t; to declare a type
before use. If you wanted to add support for attributes which
apply to multiple types, you could put those after a comma after
the type my_type_t portion of the type declaration.
Well, I'm interested in seeing the actual code, not the same kind
of thing as arguement.
Ok, you want sample policy to match your MLS sample? For
convenience here's one more macro:
define(`rx',`r(`$1',`$2') x(`$1',`$2')')
type unclass;
type c;
type s;
type ts;
rx(c, unclass)
rx(s, c)
rx(s, unclass)
rx(ts, s)
rx(ts, c)
rx(ts, unclass)
In case you don't have the policy you typed into your email, it looks
almost identical with a few exceptions for slightly modified syntax:
CUnclass rx
SC rx
SUnclass rx
TS S rx
TS C rx
TS Unclass rx
Smack rule sets can be easily defined that describe
BellLaPadula sensitivity, Biba integrity, and a variety of
interesting configurations. Smack rule sets can be modified on
the fly to accomodate changes in the operating environment or
even the time of day.
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
You have to build the booleans into the policy in advance.
Well, yes, but a policy which completely ignores
This
