From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p0QIGUZN024994 for ; Wed, 26 Jan 2011 13:16:30 -0500 Received: from ams-iport-2.cisco.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p0QIGNSr019514 for ; Wed, 26 Jan 2011 18:16:23 GMT Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0QIGMR0016620 for ; Wed, 26 Jan 2011 18:16:22 GMT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBD85.2266D0F5" Subject: SeLinux Policy design question Date: Wed, 26 Jan 2011 19:16:21 +0100 Message-ID: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> From: "Ger Lawlor (gelawlor)" To: Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBD85.2266D0F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 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=20 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.=20 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=20 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? =20 Thanks. Ger. ------_=_NextPart_001_01CBBD85.2266D0F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

------_=_NextPart_001_01CBBD85.2266D0F5-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p0QKGnMV000851 for ; Wed, 26 Jan 2011 15:16:49 -0500 Received: from mail-ww0-f49.google.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p0QKGmwL025516 for ; Wed, 26 Jan 2011 20:16:48 GMT Received: by wwb17 with SMTP id 17so1399160wwb.30 for ; Wed, 26 Jan 2011 12:16:47 -0800 (PST) Message-ID: <4D40812C.4060004@gmail.com> Date: Wed, 26 Jan 2011 21:16:44 +0100 From: Dominick Grift MIME-Version: 1.0 To: "Ger Lawlor (gelawlor)" CC: selinux@tycho.nsa.gov Subject: Re: SeLinux Policy design question References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> In-Reply-To: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p0QKZ9wT001779 for ; Wed, 26 Jan 2011 15:35:09 -0500 Received: from mail-yx0-f181.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p0QKZ8hj015151 for ; Wed, 26 Jan 2011 20:35:08 GMT Received: by yxd39 with SMTP id 39so311815yxd.12 for ; Wed, 26 Jan 2011 12:35:08 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D40812C.4060004@gmail.com> References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D40812C.4060004@gmail.com> Date: Wed, 26 Jan 2011 12:35:07 -0800 Message-ID: Subject: Re: SeLinux Policy design question From: Ethan Heidrick To: selinux@tycho.nsa.gov Content-Type: multipart/alternative; boundary=000e0cd5d022c97c9d049ac5c4d4 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --000e0cd5d022c97c9d049ac5c4d4 Content-Type: text/plain; charset=ISO-8859-1 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 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. > --000e0cd5d022c97c9d049ac5c4d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello Ger,

having a suite as you refer to as managing sys is a produ= ct inside the array.=A0
I may be misinformed but writing a policy that = allows socketing for the desired
services will allow for a better acces= s 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 context= s
> and transitions in SeLinux.
>
> If I have a suite of services that interface within a single product a= nd
> 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<= br> > 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 wou= ld
> not be considered a suitable initial approach to seLinux development,<= br> > with continued
>
> Evolution, adding contexts for further refinement of control over time= ?
> Are there best practice guides to filesystem labeling that considers t= he
> complexity that can
>
> Come from excessive labeling?

In my experience it is probably easier and safer to design poli= cy 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
=3DIuF6
-----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.

--000e0cd5d022c97c9d049ac5c4d4-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p0UMKReD009013 for ; Sun, 30 Jan 2011 17:20:27 -0500 Received: from flower.research.telcordia.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p0UMKQYI010601 for ; Sun, 30 Jan 2011 22:20:26 GMT Received: from [128.96.58.28] ([128.96.58.28]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p0UMKQGM018994 for ; Sun, 30 Jan 2011 17:20:26 -0500 (EST) Message-ID: <4D45E42A.80303@research.telcordia.com> Date: Sun, 30 Jan 2011 17:20:26 -0500 From: Sanjai Narain MIME-Version: 1.0 CC: selinux@tycho.nsa.gov Subject: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> In-Reply-To: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> Content-Type: multipart/alternative; boundary="------------080605020002000206020707" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------080605020002000206020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Has there been thinking on whether SELinux-hardened machines can avoid the spread of Stuxnet-like worms? Thanks. --Sanjai --------------080605020002000206020707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Has there been thinking on whether SELinux-hardened machines can avoid the spread of Stuxnet-like worms? Thanks. --Sanjai

--------------080605020002000206020707-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p0V0dnYm014487 for ; Sun, 30 Jan 2011 19:39:49 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p0V0dmvc022997 for ; Mon, 31 Jan 2011 00:39:48 GMT Message-ID: <4D4604DB.3060402@itechfrontiers.com> Date: Sun, 30 Jan 2011 19:39:55 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Sanjai Narain CC: selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> In-Reply-To: <4D45E42A.80303@research.telcordia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MGriDI006146 for ; Tue, 22 Feb 2011 11:53:44 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MGrhoV025555 for ; Tue, 22 Feb 2011 16:53:43 GMT Message-ID: <4D63EA14.2080701@itechfrontiers.com> Date: Tue, 22 Feb 2011 11:53:40 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Sanjai Narain CC: selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> In-Reply-To: <4D4604DB.3060402@itechfrontiers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MHJRio007777 for ; Tue, 22 Feb 2011 12:19:27 -0500 Received: from flower.research.telcordia.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MHJQfg027357 for ; Tue, 22 Feb 2011 17:19:26 GMT Received: from [192.4.12.209] (ar12-209.research.telcordia.com [192.4.12.209]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p1MHJQEj006117 for ; Tue, 22 Feb 2011 12:19:26 -0500 (EST) Message-ID: <4D63F01E.70903@research.telcordia.com> Date: Tue, 22 Feb 2011 12:19:26 -0500 From: Sanjai Narain MIME-Version: 1.0 CC: selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> In-Reply-To: <4D63EA14.2080701@itechfrontiers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MHhFZF009064 for ; Tue, 22 Feb 2011 12:43:15 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MHhAfg002559 for ; Tue, 22 Feb 2011 17:43:10 GMT Message-ID: <4D63F5A9.3000301@itechfrontiers.com> Date: Tue, 22 Feb 2011 12:43:05 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Sanjai Narain CC: selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> In-Reply-To: <4D63F01E.70903@research.telcordia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MHsYWA009622 for ; Tue, 22 Feb 2011 12:54:34 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MHsXfg005105 for ; Tue, 22 Feb 2011 17:54:33 GMT Message-ID: <4D63F854.3030907@itechfrontiers.com> Date: Tue, 22 Feb 2011 12:54:28 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Sanjai Narain CC: selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> <4D63F5A9.3000301@itechfrontiers.com> In-Reply-To: <4D63F5A9.3000301@itechfrontiers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MLlokn021273 for ; Tue, 22 Feb 2011 16:47:50 -0500 Received: from mail-gy0-f181.google.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MLlncZ026889 for ; Tue, 22 Feb 2011 21:47:49 GMT Received: by gyd10 with SMTP id 10so1273930gyd.12 for ; Tue, 22 Feb 2011 13:47:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D63F854.3030907@itechfrontiers.com> References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> <4D63F5A9.3000301@itechfrontiers.com> <4D63F854.3030907@itechfrontiers.com> Date: Tue, 22 Feb 2011 13:47:49 -0800 Message-ID: Subject: Re: SELinux and Stuxnet From: Ethan Heidrick To: "cto@itechfrontiers.com" Cc: Sanjai Narain , selinux@tycho.nsa.gov Content-Type: multipart/alternative; boundary=000e0cd30b527855de049ce5eecf Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --000e0cd30b527855de049ce5eecf Content-Type: text/plain; charset=ISO-8859-1 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. > --000e0cd30b527855de049ce5eecf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IE: infrastructure is process based on detecting such side channeling attac= ks excuse the pun, but revising SeLinux security authorization if that is w= hat you are suggesting would create an independent node of programmable pat= ches directed specific technique.

Where would an node discrimination in the coding be "hazardous&quo= t; 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 my= self, 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:
=A0Sanjai,

=A0Security is a complex business, I'm afraid that SELINUX is an attemp= t to
=A0simplify part of this job at least,

=A0The more secure you want to make a system the more complex naturally it<= br> =A0becomes,

=A0however complexity is enemy of security by itself,

=A0There is somewhat a dilemma, a paradox in here, I'm afraid it cannot= be
=A0oversimplified as regular users would become security experts or such =A0simplification waves the need for security specialists

=A0Best,

=A0Patrick 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@tych= o.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.

--000e0cd30b527855de049ce5eecf-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1MME2k6022557 for ; Tue, 22 Feb 2011 17:14:03 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p1MME28e016180 for ; Tue, 22 Feb 2011 22:14:02 GMT Message-ID: <4D643523.7040907@itechfrontiers.com> Date: Tue, 22 Feb 2011 17:13:55 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Ethan Heidrick CC: Sanjai Narain , selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> <4D63F5A9.3000301@itechfrontiers.com> <4D63F854.3030907@itechfrontiers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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 > > 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.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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1N2sZsw002319 for ; Tue, 22 Feb 2011 21:54:35 -0500 Received: from mail-yw0-f53.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p1N2sYkO008326 for ; Wed, 23 Feb 2011 02:54:34 GMT Received: by ywl2 with SMTP id 2so930951ywl.12 for ; Tue, 22 Feb 2011 18:54:34 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D643523.7040907@itechfrontiers.com> References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> <4D63F5A9.3000301@itechfrontiers.com> <4D63F854.3030907@itechfrontiers.com> <4D643523.7040907@itechfrontiers.com> Date: Tue, 22 Feb 2011 18:54:34 -0800 Message-ID: Subject: Re: SELinux and Stuxnet From: Ethan Heidrick To: "cto@itechfrontiers.com" Cc: Sanjai Narain , selinux@tycho.nsa.gov Content-Type: multipart/alternative; boundary=000e0cd6acd87f542d049cea37e1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --000e0cd6acd87f542d049cea37e1 Content-Type: text/plain; charset=ISO-8859-1 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 >> > >> > 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 > 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. >> >> >> > --000e0cd6acd87f542d049cea37e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The policies that are written are concerned with architecture based penetra= tion 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=A0 = data compression encryption taking advantage of the communication of proces= ses 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" f= or 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:

=A0 =A0Need to add it myself, that human being is also error-prone,

=A0 =A0i.e. last message I meant "waives" and wrote "waves&= quot;

=A0 =A0such errors happen even in development, in software and in security=



=A0 =A0On 2/22/2011 12:43 PM, cto@itechfrontiers.com
=A0 =A0<mailto:cto@itechfrontiers.com> wrote:
=A0 =A0 =A0Sanjai,

=A0 =A0 =A0Security is a complex business, I'm afraid that SELINUX is = an
=A0 =A0attempt to
=A0 =A0 =A0simplify part of this job at least,

=A0 =A0 =A0The more secure you want to make a system the more complex
=A0 =A0naturally it
=A0 =A0 =A0becomes,

=A0 =A0 =A0however complexity is enemy of security by itself,

=A0 =A0 =A0There is somewhat a dilemma, a paradox in here, I'm afraid = it
=A0 =A0cannot be
=A0 =A0 =A0oversimplified as regular users would become security experts o= r such
=A0 =A0 =A0simplification waves the need for security specialists

=A0 =A0 =A0Best,

=A0 =A0 =A0Patrick K.



=A0 =A0 =A0 =A0On 2/22/2011 12:19 PM, Sanjai Narain wrote:

=A0 =A0 =A0 =A0 =A0 =A0Hi Patrick: Thanks for your note. I understand that= SELinux
=A0 =A0 =A0 =A0 =A0 =A0does not
=A0 =A0 =A0 =A0 =A0 =A0directly apply to Stuxnet since it targeted Windows= . However, my
=A0 =A0 =A0 =A0 =A0 =A0question was conceptually motivated: whether mandat= ory
=A0 =A0 =A0 =A0 =A0 =A0access control
=A0 =A0 =A0 =A0 =A0 =A0could have contained the impact of this worm, had i= t been
=A0 =A0 =A0 =A0 =A0 =A0available. I
=A0 =A0 =A0 =A0 =A0 =A0had thought that the answer is yes but wanted to fi= nd out
=A0 =A0 =A0 =A0 =A0 =A0from other
=A0 =A0 =A0 =A0 =A0 =A0experts. I believe you concur. Now, if only we coul= d make
=A0 =A0 =A0 =A0 =A0 =A0SELinux a lot
=A0 =A0 =A0 =A0 =A0 =A0easier to use..... this is where one of my interest= s lie. --
=A0 =A0 =A0 =A0 =A0 =A0Sanjai


=A0 =A0 =A0 =A0 =A0 =A0On 2/22/2011 11:53 AM, cto@itechfrontiers.com
<= div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0<mailto:cto@itechfrontiers.com> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 1/30/2011 7:39 PM, cto@itechfrontiers.com
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:cto@itechfrontiers.com> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hello,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stuxnet is a Windows Worm, and SELi= nux is Mandatory
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Access Control for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Linux

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on Linux SELinux can reduce the imp= act of such worms
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if targeting Linux
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0boxes, but it is not a preemptive m= echanism for not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0having any kind of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compromise due to any vulnerability= , Although if you
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0protect your
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0system
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and targeted processes you may have= reach the goal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of containing the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0impact of possible compromises


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Patrick K.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 1/30/2011 5:20 PM, Sanjai Narain= wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Has there been thinking on = whether
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SELinux-hardened machines c= an avoid
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the spread of Stuxnet-like = worms? Thanks. --Sanjai



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This message was distributed to sub= scribers of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0selinux mailing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0list.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If you no longer wish to subscribe,= send mail to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov<= /a>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the words "unsubscribe selinux= " without quotes as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the message.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sanjai,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SELinux is Mandatory Access Control for Lin= ux

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stuxnet only compromises Windows, SCADA and= PLC 7
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0systems (Siemens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0systems)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it is a worm, for a worm to compromise a sy= stem you need
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0certain vulnerabilities

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It cannot compromise Linux (the same way); = as that worm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has been
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0designed for particular purposes and taking= advantages
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of Windows
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vulnerabilities

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If you mean protecting a network using Linu= x front ends
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or inline
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0systems Like IPS systems that's another= story which is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irrelevant to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SELINUX actually (although an IPS system -I= ntrusion
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Prevention system-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on Linux can take advantages of SELINUX)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in brief , theoretically in case of a worm = for Linux, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0could be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contained if SELINUX is effectively used.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in practice Stuxnet is for Windows

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Patrick K.




=A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0This message was distributed to subscribers of the selinux<= br> =A0 =A0 =A0 =A0mailing list.
=A0 =A0 =A0 =A0If you no longer wish to subscribe, send mail to
<= /div> =A0 =A0 =A0 =A0majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov>

=A0 =A0 =A0 =A0with
=A0 =A0 =A0 =A0the words "unsubscribe selinux" without quotes as= the message.



=A0 =A0--
=A0 =A0This message was distributed to subscribers of the selinux mailing = list.
=A0 =A0If you no longer wish to subscribe, send mail to
=A0 =A0majord= omo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> with
=A0 =A0the words "unsubscribe selinux" without quotes as the mes= sage.




--000e0cd6acd87f542d049cea37e1-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p1N3fohH004427 for ; Tue, 22 Feb 2011 22:41:51 -0500 Received: from c-sl428.itechfrontiers.net (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p1N3fnkO015105 for ; Wed, 23 Feb 2011 03:41:49 GMT Message-ID: <4D6481FB.9050105@itechfrontiers.com> Date: Tue, 22 Feb 2011 22:41:47 -0500 From: "cto@itechfrontiers.com" MIME-Version: 1.0 To: Ethan Heidrick CC: Sanjai Narain , selinux@tycho.nsa.gov Subject: Re: SELinux and Stuxnet References: <0B31D28E10F4FA489A0261135B94A14804A4489F@XMB-AMS-109.cisco.com> <4D45E42A.80303@research.telcordia.com> <4D4604DB.3060402@itechfrontiers.com> <4D63EA14.2080701@itechfrontiers.com> <4D63F01E.70903@research.telcordia.com> <4D63F5A9.3000301@itechfrontiers.com> <4D63F854.3030907@itechfrontiers.com> <4D643523.7040907@itechfrontiers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov > ... 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 > > 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 > > > > > > >> > 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.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.