All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.