* SeLinux Policy design question @ 2011-01-26 18:16 Ger Lawlor (gelawlor) 2011-01-26 20:16 ` Dominick Grift 2011-01-30 22:20 ` SELinux and Stuxnet Sanjai Narain 0 siblings, 2 replies; 13+ messages in thread From: Ger Lawlor (gelawlor) @ 2011-01-26 18:16 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1094 bytes --] Hi, I am pondering the best approach to design of appropriate filesystem labeling that will reduce the long term complexity of managing contexts and transitions in SeLinux. If I have a suite of services that interface within a single product and those services have the potential to share access to similar sub directory structures, but they currently only access files and execute within their own install directories. It's obviously better to keep locked down any access outside of each services domain. However, what if all services within a product were permitted open access to all known directories within a product - apart from the obvious i.e. these services could Interfere with each other, are there any reasons why this approach would not be considered a suitable initial approach to seLinux development, with continued Evolution, adding contexts for further refinement of control over time? Are there best practice guides to filesystem labeling that considers the complexity that can Come from excessive labeling? Thanks. Ger. [-- Attachment #2: Type: text/html, Size: 3004 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SeLinux Policy design question 2011-01-26 18:16 SeLinux Policy design question Ger Lawlor (gelawlor) @ 2011-01-26 20:16 ` Dominick Grift 2011-01-26 20:35 ` Ethan Heidrick 2011-01-30 22:20 ` SELinux and Stuxnet Sanjai Narain 1 sibling, 1 reply; 13+ messages in thread From: Dominick Grift @ 2011-01-26 20:16 UTC (permalink / raw) To: Ger Lawlor (gelawlor); +Cc: selinux -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 07:16 PM, Ger Lawlor (gelawlor) wrote: > Hi, > > > > I am pondering the best approach to design of appropriate filesystem > labeling that will reduce the long term complexity of managing contexts > and transitions in SeLinux. > > If I have a suite of services that interface within a single product and > those services have the potential to share access to similar sub > directory structures, but they > > currently only access files and execute within their own install > directories. It's obviously better to keep locked down any access > outside of each services domain. > > However, what if all services within a product were permitted open > access to all known directories within a product - apart from the > obvious i.e. these services could > > Interfere with each other, are there any reasons why this approach would > not be considered a suitable initial approach to seLinux development, > with continued > > Evolution, adding contexts for further refinement of control over time? > Are there best practice guides to filesystem labeling that considers the > complexity that can > > Come from excessive labeling? In my experience it is probably easier and safer to design policy as fine grained as you need to initially. Because it is in my experience easier to allow a restricted domain some extra permissions over time that it may need later than it is to restrict generic domain for a particular process. For example: Lets say you start as generic as possible and create a single domain where all the services in your suite runs in. That means that this single generic domain needs all permissions required to allow each service to function properly. Then later you decide to create a new domain for one of the services in your suite. That service requires a unique permission. That would then mean that your initial generic domain can drop that permission. Because the service that needs it now runs in its own domain with its own permission set. In theory if you know that the permission in question is unique then its easy to just remove that from the generic domain, however in practice it is not that easy to determine that it is unique and only required by a specific service. And so chances are that the initial generic domain becomes more permissive than it has to be. If this only applies to a single domain, then this is not such a big deal, because once you got to confining each other service in your suite over time, you could just revisit the initial more generic domain. But the more generic confined domains you have the harder it gets. It is in my view i guess a balance of priorities. I would probably keep my policy under development until i reached all my security goals, and then deploy it. But you may not have this luxury. You can choose you start with some generic domain to dump all your targeted processes in and refine policy later but basically you may end up with extra work, just to be able to basically deploy an unfinished policy. Besides in either case you run the risk of having to maintain policy over time any ways. But as for overall, keep it as generic as possible to reduce complexity, but not at the cost of not meeting your security goals. Because that's eventually what it is all about (meeting all your security goals. Disclaimer: I am not a professional security expert and so my suggestions may be fundamentally wrong. Use my advice at your own risk. > > > Thanks. > > Ger. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AgSsACgkQMlxVo39jgT8sPgCfTurKF2uof7bYDPG01Mwb+54X nNsAoLFJNtd/+NYh0NwwL8krb6iDmAqs =IuF6 -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SeLinux Policy design question 2011-01-26 20:16 ` Dominick Grift @ 2011-01-26 20:35 ` Ethan Heidrick 0 siblings, 0 replies; 13+ messages in thread From: Ethan Heidrick @ 2011-01-26 20:35 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 4545 bytes --] hello Ger, having a suite as you refer to as managing sys is a product inside the array. I may be misinformed but writing a policy that allows socketing for the desired services will allow for a better access measure for both the sys and the user context hope that helps, en On Wed, Jan 26, 2011 at 12:16 PM, Dominick Grift <domg472@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/26/2011 07:16 PM, Ger Lawlor (gelawlor) wrote: > > Hi, > > > > > > > > I am pondering the best approach to design of appropriate filesystem > > labeling that will reduce the long term complexity of managing contexts > > and transitions in SeLinux. > > > > If I have a suite of services that interface within a single product and > > those services have the potential to share access to similar sub > > directory structures, but they > > > > currently only access files and execute within their own install > > directories. It's obviously better to keep locked down any access > > outside of each services domain. > > > > However, what if all services within a product were permitted open > > access to all known directories within a product - apart from the > > obvious i.e. these services could > > > > Interfere with each other, are there any reasons why this approach would > > not be considered a suitable initial approach to seLinux development, > > with continued > > > > Evolution, adding contexts for further refinement of control over time? > > Are there best practice guides to filesystem labeling that considers the > > complexity that can > > > > Come from excessive labeling? > > In my experience it is probably easier and safer to design policy as > fine grained as you need to initially. Because it is in my experience > easier to allow a restricted domain some extra permissions over time > that it may need later than it is to restrict generic domain for a > particular process. > > For example: > > Lets say you start as generic as possible and create a single domain > where all the services in your suite runs in. That means that this > single generic domain needs all permissions required to allow each > service to function properly. > > Then later you decide to create a new domain for one of the services in > your suite. That service requires a unique permission. That would then > mean that your initial generic domain can drop that permission. Because > the service that needs it now runs in its own domain with its own > permission set. > > In theory if you know that the permission in question is unique then its > easy to just remove that from the generic domain, however in practice it > is not that easy to determine that it is unique and only required by a > specific service. > > And so chances are that the initial generic domain becomes more > permissive than it has to be. > > If this only applies to a single domain, then this is not such a big > deal, because once you got to confining each other service in your suite > over time, you could just revisit the initial more generic domain. > > But the more generic confined domains you have the harder it gets. > > It is in my view i guess a balance of priorities. I would probably keep > my policy under development until i reached all my security goals, and > then deploy it. But you may not have this luxury. > > You can choose you start with some generic domain to dump all your > targeted processes in and refine policy later but basically you may end > up with extra work, just to be able to basically deploy an unfinished > policy. > > Besides in either case you run the risk of having to maintain policy > over time any ways. > > But as for overall, keep it as generic as possible to reduce complexity, > but not at the cost of not meeting your security goals. > Because that's eventually what it is all about (meeting all your > security goals. > > Disclaimer: I am not a professional security expert and so my > suggestions may be fundamentally wrong. Use my advice at your own risk. > > > > > > > Thanks. > > > > Ger. > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1AgSsACgkQMlxVo39jgT8sPgCfTurKF2uof7bYDPG01Mwb+54X > nNsAoLFJNtd/+NYh0NwwL8krb6iDmAqs > =IuF6 > -----END PGP SIGNATURE----- > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith > the words "unsubscribe selinux" without quotes as the message. > [-- Attachment #2: Type: text/html, Size: 5471 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* SELinux and Stuxnet 2011-01-26 18:16 SeLinux Policy design question Ger Lawlor (gelawlor) 2011-01-26 20:16 ` Dominick Grift @ 2011-01-30 22:20 ` Sanjai Narain 2011-01-31 0:39 ` cto 1 sibling, 1 reply; 13+ messages in thread From: Sanjai Narain @ 2011-01-30 22:20 UTC (permalink / raw) Cc: selinux [-- Attachment #1: Type: text/plain, Size: 124 bytes --] Has there been thinking on whether SELinux-hardened machines can avoid the spread of Stuxnet-like worms? Thanks. --Sanjai [-- Attachment #2: Type: text/html, Size: 453 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-01-30 22:20 ` SELinux and Stuxnet Sanjai Narain @ 2011-01-31 0:39 ` cto 2011-02-22 16:53 ` cto 0 siblings, 1 reply; 13+ messages in thread From: cto @ 2011-01-31 0:39 UTC (permalink / raw) To: Sanjai Narain; +Cc: selinux Hello, Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for Linux on Linux SELinux can reduce the impact of such worms if targeting Linux boxes, but it is not a preemptive mechanism for not having any kind of compromise due to any vulnerability, Although if you protect your system and targeted processes you may have reach the goal of containing the impact of possible compromises Best, Patrick K. On 1/30/2011 5:20 PM, Sanjai Narain wrote: > Has there been thinking on whether SELinux-hardened machines can avoid > the spread of Stuxnet-like worms? Thanks. --Sanjai > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-01-31 0:39 ` cto @ 2011-02-22 16:53 ` cto 2011-02-22 17:19 ` Sanjai Narain 0 siblings, 1 reply; 13+ messages in thread From: cto @ 2011-02-22 16:53 UTC (permalink / raw) To: Sanjai Narain; +Cc: selinux On 1/30/2011 7:39 PM, cto@itechfrontiers.com wrote: > Hello, > > Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for > Linux > > on Linux SELinux can reduce the impact of such worms if targeting Linux > boxes, but it is not a preemptive mechanism for not having any kind of > compromise due to any vulnerability, Although if you protect your system > and targeted processes you may have reach the goal of containing the > impact of possible compromises > > > Best, > > Patrick K. > > On 1/30/2011 5:20 PM, Sanjai Narain wrote: >> Has there been thinking on whether SELinux-hardened machines can avoid >> the spread of Stuxnet-like worms? Thanks. --Sanjai >> > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. Sanjai, SELinux is Mandatory Access Control for Linux Stuxnet only compromises Windows, SCADA and PLC 7 systems (Siemens systems) it is a worm, for a worm to compromise a system you need to have certain vulnerabilities It cannot compromise Linux (the same way); as that worm has been designed for particular purposes and taking advantages of Windows vulnerabilities If you mean protecting a network using Linux front ends or inline systems Like IPS systems that's another story which is irrelevant to SELINUX actually (although an IPS system -Intrusion Prevention system- on Linux can take advantages of SELINUX) in brief , theoretically in case of a worm for Linux, it could be contained if SELINUX is effectively used. in practice Stuxnet is for Windows Best, Patrick K. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 16:53 ` cto @ 2011-02-22 17:19 ` Sanjai Narain 2011-02-22 17:43 ` cto 0 siblings, 1 reply; 13+ messages in thread From: Sanjai Narain @ 2011-02-22 17:19 UTC (permalink / raw) Cc: selinux Hi Patrick: Thanks for your note. I understand that SELinux does not directly apply to Stuxnet since it targeted Windows. However, my question was conceptually motivated: whether mandatory access control could have contained the impact of this worm, had it been available. I had thought that the answer is yes but wanted to find out from other experts. I believe you concur. Now, if only we could make SELinux a lot easier to use..... this is where one of my interests lie. -- Sanjai On 2/22/2011 11:53 AM, cto@itechfrontiers.com wrote: > On 1/30/2011 7:39 PM, cto@itechfrontiers.com wrote: >> Hello, >> >> Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for >> Linux >> >> on Linux SELinux can reduce the impact of such worms if targeting Linux >> boxes, but it is not a preemptive mechanism for not having any kind of >> compromise due to any vulnerability, Although if you protect your system >> and targeted processes you may have reach the goal of containing the >> impact of possible compromises >> >> >> Best, >> >> Patrick K. >> >> On 1/30/2011 5:20 PM, Sanjai Narain wrote: >>> Has there been thinking on whether SELinux-hardened machines can avoid >>> the spread of Stuxnet-like worms? Thanks. --Sanjai >>> >> >> >> -- >> This message was distributed to subscribers of the selinux mailing list. >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov >> with >> the words "unsubscribe selinux" without quotes as the message. > > Sanjai, > > SELinux is Mandatory Access Control for Linux > > Stuxnet only compromises Windows, SCADA and PLC 7 systems (Siemens > systems) > > it is a worm, for a worm to compromise a system you need to have > certain vulnerabilities > > It cannot compromise Linux (the same way); as that worm has been > designed for particular purposes and taking advantages of Windows > vulnerabilities > > If you mean protecting a network using Linux front ends or inline > systems Like IPS systems that's another story which is irrelevant to > SELINUX actually (although an IPS system -Intrusion Prevention > system- on Linux can take advantages of SELINUX) > > in brief , theoretically in case of a worm for Linux, it could be > contained if SELINUX is effectively used. > > in practice Stuxnet is for Windows > > Best, > > Patrick K. > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 17:19 ` Sanjai Narain @ 2011-02-22 17:43 ` cto 2011-02-22 17:54 ` cto 0 siblings, 1 reply; 13+ messages in thread From: cto @ 2011-02-22 17:43 UTC (permalink / raw) To: Sanjai Narain; +Cc: selinux Sanjai, Security is a complex business, I'm afraid that SELINUX is an attempt to simplify part of this job at least, The more secure you want to make a system the more complex naturally it becomes, however complexity is enemy of security by itself, There is somewhat a dilemma, a paradox in here, I'm afraid it cannot be oversimplified as regular users would become security experts or such simplification waves the need for security specialists Best, Patrick K. On 2/22/2011 12:19 PM, Sanjai Narain wrote: > Hi Patrick: Thanks for your note. I understand that SELinux does not > directly apply to Stuxnet since it targeted Windows. However, my > question was conceptually motivated: whether mandatory access control > could have contained the impact of this worm, had it been available. I > had thought that the answer is yes but wanted to find out from other > experts. I believe you concur. Now, if only we could make SELinux a lot > easier to use..... this is where one of my interests lie. -- Sanjai > > > On 2/22/2011 11:53 AM, cto@itechfrontiers.com wrote: >> On 1/30/2011 7:39 PM, cto@itechfrontiers.com wrote: >>> Hello, >>> >>> Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for >>> Linux >>> >>> on Linux SELinux can reduce the impact of such worms if targeting Linux >>> boxes, but it is not a preemptive mechanism for not having any kind of >>> compromise due to any vulnerability, Although if you protect your system >>> and targeted processes you may have reach the goal of containing the >>> impact of possible compromises >>> >>> >>> Best, >>> >>> Patrick K. >>> >>> On 1/30/2011 5:20 PM, Sanjai Narain wrote: >>>> Has there been thinking on whether SELinux-hardened machines can avoid >>>> the spread of Stuxnet-like worms? Thanks. --Sanjai >>>> >>> >>> >>> -- >>> This message was distributed to subscribers of the selinux mailing list. >>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov >>> with >>> the words "unsubscribe selinux" without quotes as the message. >> >> Sanjai, >> >> SELinux is Mandatory Access Control for Linux >> >> Stuxnet only compromises Windows, SCADA and PLC 7 systems (Siemens >> systems) >> >> it is a worm, for a worm to compromise a system you need to have >> certain vulnerabilities >> >> It cannot compromise Linux (the same way); as that worm has been >> designed for particular purposes and taking advantages of Windows >> vulnerabilities >> >> If you mean protecting a network using Linux front ends or inline >> systems Like IPS systems that's another story which is irrelevant to >> SELINUX actually (although an IPS system -Intrusion Prevention system- >> on Linux can take advantages of SELINUX) >> >> in brief , theoretically in case of a worm for Linux, it could be >> contained if SELINUX is effectively used. >> >> in practice Stuxnet is for Windows >> >> Best, >> >> Patrick K. >> >> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 17:43 ` cto @ 2011-02-22 17:54 ` cto 2011-02-22 21:47 ` Ethan Heidrick 0 siblings, 1 reply; 13+ messages in thread From: cto @ 2011-02-22 17:54 UTC (permalink / raw) To: Sanjai Narain; +Cc: selinux Need to add it myself, that human being is also error-prone, i.e. last message I meant "waives" and wrote "waves" such errors happen even in development, in software and in security On 2/22/2011 12:43 PM, cto@itechfrontiers.com wrote: Sanjai, Security is a complex business, I'm afraid that SELINUX is an attempt to simplify part of this job at least, The more secure you want to make a system the more complex naturally it becomes, however complexity is enemy of security by itself, There is somewhat a dilemma, a paradox in here, I'm afraid it cannot be oversimplified as regular users would become security experts or such simplification waves the need for security specialists Best, Patrick K. > > > On 2/22/2011 12:19 PM, Sanjai Narain wrote: >> Hi Patrick: Thanks for your note. I understand that SELinux does not >> directly apply to Stuxnet since it targeted Windows. However, my >> question was conceptually motivated: whether mandatory access control >> could have contained the impact of this worm, had it been available. I >> had thought that the answer is yes but wanted to find out from other >> experts. I believe you concur. Now, if only we could make SELinux a lot >> easier to use..... this is where one of my interests lie. -- Sanjai >> >> >> On 2/22/2011 11:53 AM, cto@itechfrontiers.com wrote: >>> On 1/30/2011 7:39 PM, cto@itechfrontiers.com wrote: >>>> Hello, >>>> >>>> Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for >>>> Linux >>>> >>>> on Linux SELinux can reduce the impact of such worms if targeting Linux >>>> boxes, but it is not a preemptive mechanism for not having any kind of >>>> compromise due to any vulnerability, Although if you protect your >>>> system >>>> and targeted processes you may have reach the goal of containing the >>>> impact of possible compromises >>>> >>>> >>>> Best, >>>> >>>> Patrick K. >>>> >>>> On 1/30/2011 5:20 PM, Sanjai Narain wrote: >>>>> Has there been thinking on whether SELinux-hardened machines can avoid >>>>> the spread of Stuxnet-like worms? Thanks. --Sanjai >>>>> >>>> >>>> >>>> -- >>>> This message was distributed to subscribers of the selinux mailing >>>> list. >>>> If you no longer wish to subscribe, send mail to >>>> majordomo@tycho.nsa.gov >>>> with >>>> the words "unsubscribe selinux" without quotes as the message. >>> >>> Sanjai, >>> >>> SELinux is Mandatory Access Control for Linux >>> >>> Stuxnet only compromises Windows, SCADA and PLC 7 systems (Siemens >>> systems) >>> >>> it is a worm, for a worm to compromise a system you need to have >>> certain vulnerabilities >>> >>> It cannot compromise Linux (the same way); as that worm has been >>> designed for particular purposes and taking advantages of Windows >>> vulnerabilities >>> >>> If you mean protecting a network using Linux front ends or inline >>> systems Like IPS systems that's another story which is irrelevant to >>> SELINUX actually (although an IPS system -Intrusion Prevention system- >>> on Linux can take advantages of SELINUX) >>> >>> in brief , theoretically in case of a worm for Linux, it could be >>> contained if SELINUX is effectively used. >>> >>> in practice Stuxnet is for Windows >>> >>> Best, >>> >>> Patrick K. >>> >>> > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 17:54 ` cto @ 2011-02-22 21:47 ` Ethan Heidrick 2011-02-22 22:13 ` cto 0 siblings, 1 reply; 13+ messages in thread From: Ethan Heidrick @ 2011-02-22 21:47 UTC (permalink / raw) To: cto@itechfrontiers.com; +Cc: Sanjai Narain, selinux [-- Attachment #1: Type: text/plain, Size: 4311 bytes --] IE: infrastructure is process based on detecting such side channeling attacks excuse the pun, but revising SeLinux security authorization if that is what you are suggesting would create an independent node of programmable patches directed specific technique. Where would an node discrimination in the coding be "hazardous" for such red team analysis for penetration? On Tue, Feb 22, 2011 at 9:54 AM, cto@itechfrontiers.com < cto@itechfrontiers.com> wrote: > Need to add it myself, that human being is also error-prone, > > i.e. last message I meant "waives" and wrote "waves" > > such errors happen even in development, in software and in security > > > > On 2/22/2011 12:43 PM, cto@itechfrontiers.com wrote: > Sanjai, > > Security is a complex business, I'm afraid that SELINUX is an attempt to > simplify part of this job at least, > > The more secure you want to make a system the more complex naturally it > becomes, > > however complexity is enemy of security by itself, > > There is somewhat a dilemma, a paradox in here, I'm afraid it cannot be > oversimplified as regular users would become security experts or such > simplification waves the need for security specialists > > Best, > > Patrick K. > > >> >> On 2/22/2011 12:19 PM, Sanjai Narain wrote: >> >>> Hi Patrick: Thanks for your note. I understand that SELinux does not >>> directly apply to Stuxnet since it targeted Windows. However, my >>> question was conceptually motivated: whether mandatory access control >>> could have contained the impact of this worm, had it been available. I >>> had thought that the answer is yes but wanted to find out from other >>> experts. I believe you concur. Now, if only we could make SELinux a lot >>> easier to use..... this is where one of my interests lie. -- Sanjai >>> >>> >>> On 2/22/2011 11:53 AM, cto@itechfrontiers.com wrote: >>> >>>> On 1/30/2011 7:39 PM, cto@itechfrontiers.com wrote: >>>> >>>>> Hello, >>>>> >>>>> Stuxnet is a Windows Worm, and SELinux is Mandatory Access Control for >>>>> Linux >>>>> >>>>> on Linux SELinux can reduce the impact of such worms if targeting Linux >>>>> boxes, but it is not a preemptive mechanism for not having any kind of >>>>> compromise due to any vulnerability, Although if you protect your >>>>> system >>>>> and targeted processes you may have reach the goal of containing the >>>>> impact of possible compromises >>>>> >>>>> >>>>> Best, >>>>> >>>>> Patrick K. >>>>> >>>>> On 1/30/2011 5:20 PM, Sanjai Narain wrote: >>>>> >>>>>> Has there been thinking on whether SELinux-hardened machines can avoid >>>>>> the spread of Stuxnet-like worms? Thanks. --Sanjai >>>>>> >>>>>> >>>>> >>>>> -- >>>>> This message was distributed to subscribers of the selinux mailing >>>>> list. >>>>> If you no longer wish to subscribe, send mail to >>>>> majordomo@tycho.nsa.gov >>>>> with >>>>> the words "unsubscribe selinux" without quotes as the message. >>>>> >>>> >>>> Sanjai, >>>> >>>> SELinux is Mandatory Access Control for Linux >>>> >>>> Stuxnet only compromises Windows, SCADA and PLC 7 systems (Siemens >>>> systems) >>>> >>>> it is a worm, for a worm to compromise a system you need to have >>>> certain vulnerabilities >>>> >>>> It cannot compromise Linux (the same way); as that worm has been >>>> designed for particular purposes and taking advantages of Windows >>>> vulnerabilities >>>> >>>> If you mean protecting a network using Linux front ends or inline >>>> systems Like IPS systems that's another story which is irrelevant to >>>> SELINUX actually (although an IPS system -Intrusion Prevention system- >>>> on Linux can take advantages of SELINUX) >>>> >>>> in brief , theoretically in case of a worm for Linux, it could be >>>> contained if SELINUX is effectively used. >>>> >>>> in practice Stuxnet is for Windows >>>> >>>> Best, >>>> >>>> Patrick K. >>>> >>>> >>>> >> >> -- >> This message was distributed to subscribers of the selinux mailing list. >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov >> with >> the words "unsubscribe selinux" without quotes as the message. >> > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith > the words "unsubscribe selinux" without quotes as the message. > [-- Attachment #2: Type: text/html, Size: 5932 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 21:47 ` Ethan Heidrick @ 2011-02-22 22:13 ` cto 2011-02-23 2:54 ` Ethan Heidrick 0 siblings, 1 reply; 13+ messages in thread From: cto @ 2011-02-22 22:13 UTC (permalink / raw) To: Ethan Heidrick; +Cc: Sanjai Narain, selinux Ethan, What are you talking about? Patrick K. On 2/22/2011 4:47 PM, Ethan Heidrick wrote: > IE: infrastructure is process based on detecting such side channeling > attacks excuse the pun, but revising SeLinux security authorization if > that is what you are suggesting would create an independent node of > programmable patches directed specific technique. > > Where would an node discrimination in the coding be "hazardous" for such > red team analysis for penetration? > > On Tue, Feb 22, 2011 at 9:54 AM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> <cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com>> wrote: > > Need to add it myself, that human being is also error-prone, > > i.e. last message I meant "waives" and wrote "waves" > > such errors happen even in development, in software and in security > > > > On 2/22/2011 12:43 PM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> wrote: > Sanjai, > > Security is a complex business, I'm afraid that SELINUX is an > attempt to > simplify part of this job at least, > > The more secure you want to make a system the more complex > naturally it > becomes, > > however complexity is enemy of security by itself, > > There is somewhat a dilemma, a paradox in here, I'm afraid it > cannot be > oversimplified as regular users would become security experts or such > simplification waves the need for security specialists > > Best, > > Patrick K. > > > > On 2/22/2011 12:19 PM, Sanjai Narain wrote: > > Hi Patrick: Thanks for your note. I understand that SELinux > does not > directly apply to Stuxnet since it targeted Windows. However, my > question was conceptually motivated: whether mandatory > access control > could have contained the impact of this worm, had it been > available. I > had thought that the answer is yes but wanted to find out > from other > experts. I believe you concur. Now, if only we could make > SELinux a lot > easier to use..... this is where one of my interests lie. -- > Sanjai > > > On 2/22/2011 11:53 AM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> wrote: > > On 1/30/2011 7:39 PM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> wrote: > > Hello, > > Stuxnet is a Windows Worm, and SELinux is Mandatory > Access Control for > Linux > > on Linux SELinux can reduce the impact of such worms > if targeting Linux > boxes, but it is not a preemptive mechanism for not > having any kind of > compromise due to any vulnerability, Although if you > protect your > system > and targeted processes you may have reach the goal > of containing the > impact of possible compromises > > > Best, > > Patrick K. > > On 1/30/2011 5:20 PM, Sanjai Narain wrote: > > Has there been thinking on whether > SELinux-hardened machines can avoid > the spread of Stuxnet-like worms? Thanks. --Sanjai > > > > -- > This message was distributed to subscribers of the > selinux mailing > list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> > with > the words "unsubscribe selinux" without quotes as > the message. > > > Sanjai, > > SELinux is Mandatory Access Control for Linux > > Stuxnet only compromises Windows, SCADA and PLC 7 > systems (Siemens > systems) > > it is a worm, for a worm to compromise a system you need > to have > certain vulnerabilities > > It cannot compromise Linux (the same way); as that worm > has been > designed for particular purposes and taking advantages > of Windows > vulnerabilities > > If you mean protecting a network using Linux front ends > or inline > systems Like IPS systems that's another story which is > irrelevant to > SELINUX actually (although an IPS system -Intrusion > Prevention system- > on Linux can take advantages of SELINUX) > > in brief , theoretically in case of a worm for Linux, it > could be > contained if SELINUX is effectively used. > > in practice Stuxnet is for Windows > > Best, > > Patrick K. > > > > > -- > This message was distributed to subscribers of the selinux > mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> > with > the words "unsubscribe selinux" without quotes as the message. > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> with > the words "unsubscribe selinux" without quotes as the message. > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-22 22:13 ` cto @ 2011-02-23 2:54 ` Ethan Heidrick 2011-02-23 3:41 ` cto 0 siblings, 1 reply; 13+ messages in thread From: Ethan Heidrick @ 2011-02-23 2:54 UTC (permalink / raw) To: cto@itechfrontiers.com; +Cc: Sanjai Narain, selinux [-- Attachment #1: Type: text/plain, Size: 6453 bytes --] The policies that are written are concerned with architecture based penetration of an interconnecting tree (kernal), where SeLinux is concerned, What "blocks" of code would be advantageous for an attacker concerned with such penetration techniques such as key functions {algorithms} and data compression encryption taking advantage of the communication of processes in the tree? On Tue, Feb 22, 2011 at 2:13 PM, cto@itechfrontiers.com < cto@itechfrontiers.com> wrote: > Ethan, > > What are you talking about? > > > Patrick K. > > > On 2/22/2011 4:47 PM, Ethan Heidrick wrote: > >> IE: infrastructure is process based on detecting such side channeling >> attacks excuse the pun, but revising SeLinux security authorization if >> that is what you are suggesting would create an independent node of >> programmable patches directed specific technique. >> >> Where would an node discrimination in the coding be "hazardous" for such >> red team analysis for penetration? >> >> On Tue, Feb 22, 2011 at 9:54 AM, cto@itechfrontiers.com >> <mailto:cto@itechfrontiers.com> <cto@itechfrontiers.com >> >> <mailto:cto@itechfrontiers.com>> wrote: >> >> Need to add it myself, that human being is also error-prone, >> >> i.e. last message I meant "waives" and wrote "waves" >> >> such errors happen even in development, in software and in security >> >> >> >> On 2/22/2011 12:43 PM, cto@itechfrontiers.com >> <mailto:cto@itechfrontiers.com> wrote: >> Sanjai, >> >> Security is a complex business, I'm afraid that SELINUX is an >> attempt to >> simplify part of this job at least, >> >> The more secure you want to make a system the more complex >> naturally it >> becomes, >> >> however complexity is enemy of security by itself, >> >> There is somewhat a dilemma, a paradox in here, I'm afraid it >> cannot be >> oversimplified as regular users would become security experts or such >> simplification waves the need for security specialists >> >> Best, >> >> Patrick K. >> >> >> >> On 2/22/2011 12:19 PM, Sanjai Narain wrote: >> >> Hi Patrick: Thanks for your note. I understand that SELinux >> does not >> directly apply to Stuxnet since it targeted Windows. However, >> my >> question was conceptually motivated: whether mandatory >> access control >> could have contained the impact of this worm, had it been >> available. I >> had thought that the answer is yes but wanted to find out >> from other >> experts. I believe you concur. Now, if only we could make >> SELinux a lot >> easier to use..... this is where one of my interests lie. -- >> Sanjai >> >> >> On 2/22/2011 11:53 AM, cto@itechfrontiers.com >> <mailto:cto@itechfrontiers.com> wrote: >> >> On 1/30/2011 7:39 PM, cto@itechfrontiers.com >> <mailto:cto@itechfrontiers.com> wrote: >> >> Hello, >> >> Stuxnet is a Windows Worm, and SELinux is Mandatory >> Access Control for >> Linux >> >> on Linux SELinux can reduce the impact of such worms >> if targeting Linux >> boxes, but it is not a preemptive mechanism for not >> having any kind of >> compromise due to any vulnerability, Although if you >> protect your >> system >> and targeted processes you may have reach the goal >> of containing the >> impact of possible compromises >> >> >> Best, >> >> Patrick K. >> >> On 1/30/2011 5:20 PM, Sanjai Narain wrote: >> >> Has there been thinking on whether >> SELinux-hardened machines can avoid >> the spread of Stuxnet-like worms? Thanks. --Sanjai >> >> >> >> -- >> This message was distributed to subscribers of the >> selinux mailing >> list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov <mailto: >> majordomo@tycho.nsa.gov> >> >> with >> the words "unsubscribe selinux" without quotes as >> the message. >> >> >> Sanjai, >> >> SELinux is Mandatory Access Control for Linux >> >> Stuxnet only compromises Windows, SCADA and PLC 7 >> systems (Siemens >> systems) >> >> it is a worm, for a worm to compromise a system you need >> to have >> certain vulnerabilities >> >> It cannot compromise Linux (the same way); as that worm >> has been >> designed for particular purposes and taking advantages >> of Windows >> vulnerabilities >> >> If you mean protecting a network using Linux front ends >> or inline >> systems Like IPS systems that's another story which is >> irrelevant to >> SELINUX actually (although an IPS system -Intrusion >> Prevention system- >> on Linux can take advantages of SELINUX) >> >> in brief , theoretically in case of a worm for Linux, it >> could be >> contained if SELINUX is effectively used. >> >> in practice Stuxnet is for Windows >> >> Best, >> >> Patrick K. >> >> >> >> >> -- >> This message was distributed to subscribers of the selinux >> mailing list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> >> >> with >> the words "unsubscribe selinux" without quotes as the message. >> >> >> >> -- >> This message was distributed to subscribers of the selinux mailing >> list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> with >> >> the words "unsubscribe selinux" without quotes as the message. >> >> >> > [-- Attachment #2: Type: text/html, Size: 8766 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SELinux and Stuxnet 2011-02-23 2:54 ` Ethan Heidrick @ 2011-02-23 3:41 ` cto 0 siblings, 0 replies; 13+ messages in thread From: cto @ 2011-02-23 3:41 UTC (permalink / raw) To: Ethan Heidrick; +Cc: Sanjai Narain, selinux > ... taking advantage of the > communication of processes in the tree? to begin with virtual memory handling, LSM, network stack, signaling, polling, devices and etc There are more easier techniques for compromise, such as adding kernel module, device driver and etc. (root kit) after getting elevated access to a daemon with enough privileges (system calls) or elevated access or even easier one, in example a daemon with elevated (root) access can do almost any system/kernel call, access to /proc , direct access to devices, memory (raw), sockets and etc. as a target for compromise you can always rely on Daemons and users, Mandatory Access Control can be used to avoid elevation of access by unprivileged users/daemons, such elevation of privileges can be easy in example with finding a window of vulnerability in a daemon running on a system, some daemons need to run under root and create sub processes with dropped privileges, even RPC calls or shared memory are good points to start with SELinux is not just about protecting kernel, it is about adding Mandatory Access Control /Role Based Access Control to Linux that by default has DAC it is a matter of context based security, containing/sandboxing users, daemons and resources However another purpose of SELinux is MLS (MultiLevel Security) -classified, unclassified and etc- it is not just about protecting kernel tree, it is about not trusting users, daemons and processes in utilizing the resources, and by far restricting them to a predefined security context in that view anything run on the system can be treated as a possible point of threat to some extent also you cannot trust a user on a DAC based system, how do you enforce user not to in example chmod 777 his folder? So as you may know anything on the system can be a concern for MAC and SELinux, it actually depends on the goal and that particular system, it is not always necessary to gain root privilege when your target daemon is running on an unprivileged user (system wide) Thus actually almost anything; even codes not from the Linux kernel as you can see Best, Patrick K. On 2/22/2011 9:54 PM, Ethan Heidrick wrote: > The policies that are written are concerned with architecture based > penetration of an interconnecting tree (kernal), where SeLinux is > concerned, What "blocks" of code would be advantageous for an attacker > concerned with such penetration techniques such as key functions > {algorithms} and data compression encryption taking advantage of the > communication of processes in the tree? > > > On Tue, Feb 22, 2011 at 2:13 PM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> <cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com>> wrote: > > Ethan, > > What are you talking about? > > > Patrick K. > > > On 2/22/2011 4:47 PM, Ethan Heidrick wrote: > > IE: infrastructure is process based on detecting such side > channeling > attacks excuse the pun, but revising SeLinux security > authorization if > that is what you are suggesting would create an independent node of > programmable patches directed specific technique. > > Where would an node discrimination in the coding be "hazardous" > for such > red team analysis for penetration? > > On Tue, Feb 22, 2011 at 9:54 AM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> > <mailto:cto@itechfrontiers.com <mailto:cto@itechfrontiers.com>> > <cto@itechfrontiers.com <mailto:cto@itechfrontiers.com> > > <mailto:cto@itechfrontiers.com <mailto:cto@itechfrontiers.com>>> > wrote: > > Need to add it myself, that human being is also error-prone, > > i.e. last message I meant "waives" and wrote "waves" > > such errors happen even in development, in software and in > security > > > > On 2/22/2011 12:43 PM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> > <mailto:cto@itechfrontiers.com <mailto:cto@itechfrontiers.com>> > wrote: > Sanjai, > > Security is a complex business, I'm afraid that SELINUX is an > attempt to > simplify part of this job at least, > > The more secure you want to make a system the more complex > naturally it > becomes, > > however complexity is enemy of security by itself, > > There is somewhat a dilemma, a paradox in here, I'm afraid it > cannot be > oversimplified as regular users would become security > experts or such > simplification waves the need for security specialists > > Best, > > Patrick K. > > > > On 2/22/2011 12:19 PM, Sanjai Narain wrote: > > Hi Patrick: Thanks for your note. I understand that > SELinux > does not > directly apply to Stuxnet since it targeted Windows. > However, my > question was conceptually motivated: whether mandatory > access control > could have contained the impact of this worm, had it > been > available. I > had thought that the answer is yes but wanted to > find out > from other > experts. I believe you concur. Now, if only we could > make > SELinux a lot > easier to use..... this is where one of my interests > lie. -- > Sanjai > > > On 2/22/2011 11:53 AM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> > <mailto:cto@itechfrontiers.com <mailto:cto@itechfrontiers.com>> > wrote: > > On 1/30/2011 7:39 PM, cto@itechfrontiers.com > <mailto:cto@itechfrontiers.com> > <mailto:cto@itechfrontiers.com <mailto:cto@itechfrontiers.com>> > wrote: > > Hello, > > Stuxnet is a Windows Worm, and SELinux is > Mandatory > Access Control for > Linux > > on Linux SELinux can reduce the impact of > such worms > if targeting Linux > boxes, but it is not a preemptive mechanism > for not > having any kind of > compromise due to any vulnerability, > Although if you > protect your > system > and targeted processes you may have reach > the goal > of containing the > impact of possible compromises > > > Best, > > Patrick K. > > On 1/30/2011 5:20 PM, Sanjai Narain wrote: > > Has there been thinking on whether > SELinux-hardened machines can avoid > the spread of Stuxnet-like worms? > Thanks. --Sanjai > > > > -- > This message was distributed to subscribers > of the > selinux mailing > list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> > <mailto:majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov>> > > with > the words "unsubscribe selinux" without > quotes as > the message. > > > Sanjai, > > SELinux is Mandatory Access Control for Linux > > Stuxnet only compromises Windows, SCADA and PLC 7 > systems (Siemens > systems) > > it is a worm, for a worm to compromise a system > you need > to have > certain vulnerabilities > > It cannot compromise Linux (the same way); as > that worm > has been > designed for particular purposes and taking > advantages > of Windows > vulnerabilities > > If you mean protecting a network using Linux > front ends > or inline > systems Like IPS systems that's another story > which is > irrelevant to > SELINUX actually (although an IPS system -Intrusion > Prevention system- > on Linux can take advantages of SELINUX) > > in brief , theoretically in case of a worm for > Linux, it > could be > contained if SELINUX is effectively used. > > in practice Stuxnet is for Windows > > Best, > > Patrick K. > > > > > -- > This message was distributed to subscribers of the selinux > mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> > <mailto:majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov>> > > with > the words "unsubscribe selinux" without quotes as the > message. > > > > -- > This message was distributed to subscribers of the selinux > mailing list. > If you no longer wish to subscribe, send mail to > majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> > <mailto:majordomo@tycho.nsa.gov > <mailto:majordomo@tycho.nsa.gov>> with > > the words "unsubscribe selinux" without quotes as the message. > > > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-02-23 3:41 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-26 18:16 SeLinux Policy design question Ger Lawlor (gelawlor) 2011-01-26 20:16 ` Dominick Grift 2011-01-26 20:35 ` Ethan Heidrick 2011-01-30 22:20 ` SELinux and Stuxnet Sanjai Narain 2011-01-31 0:39 ` cto 2011-02-22 16:53 ` cto 2011-02-22 17:19 ` Sanjai Narain 2011-02-22 17:43 ` cto 2011-02-22 17:54 ` cto 2011-02-22 21:47 ` Ethan Heidrick 2011-02-22 22:13 ` cto 2011-02-23 2:54 ` Ethan Heidrick 2011-02-23 3:41 ` cto
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.