lids

lids

[Jeff Largent]

In just a brief look I didn't see a lot of difference
between lids and seLinux, am I missing something.


-- 
Jeff Largent                   ImageLinks, Inc.
System Admin                   Melbourne, Fl 32935
(321) 253-0011                 fax:(321) 253-5559

--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Stephen Smalley]

Security-Enhanced Linux (SELinux) has a well-defined architecture for
flexible mandatory access controls that has been experimentally
validated through several prototype systems (DTMach, DTOS, and Flask).
The architecture provides clean separation of policy from enforcement,
well-defined policy decision interfaces, flexibility in labeling and
access decisions, support for dynamic policy changes, caching to
minimize the performance overhead, and fine-grained controls over the
kernel abstractions.  Detailed studies have been performed of the ability
of the architecture to support a wide variety of security policies, and
are available through the links on the Background page.  The architecture,
interfaces, and controls are described in detail in the paper "Integrating
Flexible Support for Security Policies into the Linux Operating System"
accessible via the Documentation page.  The example security server
provided with SELinux supports Role-Based Access Control, Type
Enforcement, and optionally Multi-Level Security, and other
kinds of policies can be easily supported by the architecture.

My understanding of LIDS is that it provides support for
administratively-defined program-based ACLs for files and certain
security-critical objects (e.g. memory devices, raw devices, io ports),
controls over capabilities, "unkillable" processes, hiding 
files and processes in directory listings and /proc listings,
sending security alerts on security failures, and detecting
port scan attempts.  The first three features of LIDS are similar
to some of the SELinux mandatory access controls, but lack the
flexible support for security policies and do not address the
full set of services controlled by SELinux.  The fourth feature,
hiding file names and /proc entries, is not provided by SELinux, but
SELinux does control all attempts to access files and /proc entries.
The fifth feature, sending security alerts, has no direct equivalent in
SELinux.  SELinux does provide some simple support for selective auditing
of access grantings and/or denials based on the security policy
configuration.  However, the audit data is currently handled by the
existing kernel logging support, which we recognize as being insufficient
for auditing.  The last feature, detecting port scans, has no
relationship to mandatory access controls and consequently has no
equivalent in SELinux.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Mon, 19 Mar 2001, Jeff Largent wrote:

> In just a brief look I didn't see a lot of difference
> between lids and seLinux, am I missing something.
> 
> 
> -- 
> Jeff Largent                   ImageLinks, Inc.
> System Admin                   Melbourne, Fl 32935
> (321) 253-0011                 fax:(321) 253-5559
> 
> --
> You have received this message because you are subscribed to the selinux 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.
> 


--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Pedro Rosa]

Sorry but LIDS stands for Linux Intrusion Detection System. Its main 
purpose has nothing to do with what SELinux deals with. I don't know too 
much about the inners of LIDS but I know that it is an evolution of some 
ideas based on NIDS (Network Intrusion Detection System). Well it's a 
few monthes since I took a look at LIDS so I might be wrong in some 
point. The tool seems to follow some principles for a NIDS system but it 
is quite weaker. Besides it seems more concentrated on the inners of the 
system rather than caring about the networking environment.

In fact LIDS is a complementary  task of  what SELinux pretends to 
answer. While SELinux tries cares for the permissions of the system and 
controls their use, LIDS tries to answer for situations when such 
control is overcomed.

Ektanoor


Stephen Smalley wrote:

> Security-Enhanced Linux (SELinux) has a well-defined architecture for
> flexible mandatory access controls that has been experimentally

<skipped>

> 
> 
> 



--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Stephen Smalley]

I can't speak to the main purpose of LIDS, but the LIDS FAQ itself
mentions that LIDS implements mandatory access controls (as well as other
features). I've examined the LIDS code, and it does indeed implement such
controls.  It is true that some of the LIDS features are orthogonal to
SELinux, such as security alerts and port scan detection, but you can
certainly compare the mandatory access controls of LIDS with SELinux.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Wed, 21 Mar 2001, Pedro Rosa wrote:

> Sorry but LIDS stands for Linux Intrusion Detection System. Its main 
> purpose has nothing to do with what SELinux deals with. I don't know too 
> much about the inners of LIDS but I know that it is an evolution of some 
> ideas based on NIDS (Network Intrusion Detection System). Well it's a 
> few monthes since I took a look at LIDS so I might be wrong in some 
> point. The tool seems to follow some principles for a NIDS system but it 
> is quite weaker. Besides it seems more concentrated on the inners of the 
> system rather than caring about the networking environment.
> 
> In fact LIDS is a complementary  task of  what SELinux pretends to 
> answer. While SELinux tries cares for the permissions of the system and 
> controls their use, LIDS tries to answer for situations when such 
> control is overcomed.
> 
> Ektanoor



--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Jose Nazario]

On Wed, 21 Mar 2001, Pedro Rosa wrote:

> Sorry but LIDS stands for Linux Intrusion Detection System. Its main
> purpose has nothing to do with what SELinux deals with. I don't know
> too much about the inners of LIDS but I know that it is an evolution
> of some ideas based on NIDS (Network Intrusion Detection System).

the name LIDS is a misnomer. as someone who works a lot with IDS stuff, it
pisses me off, too, that such a fundamental mistake was made in the
naming.

http://www.lids.org/about.html

LIDS is a capability set for Linux, providing essentially a huge set of
acces controls and stuff related.

intrusion detection is the principle and practice of watching events,
comaring them to a database of signatures, and generating reports and
events based on if you match there or not. ie you could say "if you stray
outside of normal behavior signatures ...", but most have databases of
known *unwanted* behavior which match.

LIDS, while named the linux intrusion detection system, is in fact an
attempt to create the intrusion prevent system. split privilidges and
capabilities, minimize damage and abilities, etc ...

nowhere in all of the project have i seen it listed that it does IDS work.
while it may log denied attempts to, say, write to a logfile, that's a
limited view of what an IDS is all about.

as such it seems like a definite attempt to achieve similar goals as
SElinux has. smalley, i think, posted on this earlier today.

____________________________
jose nazario						     jose@cwru.edu
	      	     PGP: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
				       PGP key ID 0xFD37F4E5 (pgp.mit.edu)


--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Tracy R Reed]

On Wed, Mar 21, 2001 at 12:29:31AM +0300, Pedro Rosa wrote:
> Sorry but LIDS stands for Linux Intrusion Detection System. Its main 
> purpose has nothing to do with what SELinux deals with. I don't know too 

The name is a misnomer. It doesn't have much to do with intrusion
detection. Even the portscanner is acknowledged as not really fitting in
with the rest of the system and most believe it should be elsewhere. They
have occasionally discussed changing the name on the LIDS list where I am
a subscriber. LIDS implements MACs much like SE Linux. It has little if
anything to do with NIDS. Would you please stop ranting so much and just
spend a few days reading and considering the opinions of others?

-- 
Tracy Reed      http://www.ultraviolet.org

--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Pedro Rosa]

Jose Nazario wrote:

> On Wed, 21 Mar 2001, Pedro Rosa wrote:
> 
>> Sorry but LIDS stands for Linux Intrusion Detection System. Its main
>> purpose has nothing to do with what SELinux deals with. I don't know
>> too much about the inners of LIDS but I know that it is an evolution
>> of some ideas based on NIDS (Network Intrusion Detection System).
> 
> 
> the name LIDS is a misnomer. as someone who works a lot with IDS stuff, it
> pisses me off, too, that such a fundamental mistake was made in the
> naming.
> 
> http://www.lids.org/about.html

Well I just decided to take a walk through this LIDS world... Yes, you 
are right about the name... However this tool is far from being 
equivalent to SELinux.

ACLs are one of its main components but not the main one.
First LIDS present a series of switch options. It looks like that you 
can turn on or off this stuff in a very flexible and dynamic manner.
Second LIDS presents some features with a very non-traditional taste. 
For example, it tries to hang-up the programs that violate the 
restrictions. Besides the way programs depend on ACLs is not seen 
exactly in the same view of SELinux. Here things look more as walking on 
a minefield rather than impose an administrative order in work.
Third LIDS has tools that put it much more near a NIDS. For example it 
registers net scannings. But not only, it also tries to protect the 
system from DoS attacks based on this capability. And it tries to be 
simple and concise in reporting repeating events. 
Fourth it has a remote reporting system that sounds much like those seen 
on some monitoring systems.

I would consider that LIDS is more a tool for those users who occur to 
be in a untrusted environment or are forced to go regularly through 
such. On the contrary, SELinux sounds much more like a tool that 
guarantees the existence of a trusted environment. Besides I think that 
there is a big difference on both. On SELinux we have MACs, which seem 
controlled from a central point. On LIDS we just have a strict set of 
controls that are not controlled from any center. In fact LIDS looks 
quite autonomous in terms of setup.

Frankly I can't state anything good or bad about these two systems. They 
have clearly two different purposes. They are only similar on particular 
points but we cannot state any strongnesses or weaknesses here. In fact 
a central administration could be useless or even damaging to what LIDS 
pretends to answer. Imagine taking a trip to a foreign country with your 
notebook full of valuable data. On the other way, an administrative 
autonomy on SELinux would only rise the consume of coffee and cigarettes 
among sysadmins.

Ektanoor

> 
> 



--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Pedro Rosa]

Tracy R Reed wrote:

> On Wed, Mar 21, 2001 at 12:29:31AM +0300, Pedro Rosa wrote:
> 
>> Sorry but LIDS stands for Linux Intrusion Detection System. Its main 
>> purpose has nothing to do with what SELinux deals with. I don't know too 
> 
> 
> The name is a misnomer. It doesn't have much to do with intrusion
> detection. Even the portscanner is acknowledged as not really fitting in
> with the rest of the system and most believe it should be elsewhere. They
> have occasionally discussed changing the name on the LIDS list where I am
> a subscriber. LIDS implements MACs much like SE Linux. It has little if
> anything to do with NIDS. Would you please stop ranting so much and just
> spend a few days reading and considering the opinions of others?

Please stop the flame ok? First tell me where are the MACs in LIDS? 
Don't mess ACLs with MACs. MAC is mostly like an ACL but still needs 
that central administrative mechanism that NSA docs tell a lot about. 
And LIDS doesn't have such. Besides I did read LIDS before stating this 
stuff. Yes, it was some monthes ago on 1.0.2 (October if I'm not 
mistaken). And while I may not remember everything I read, I see that 
comparing SELinux to LIDS is the same as comparing an elephant to a 
rhinoceros.

Before teaching others, it is good to just make a pass by through the 
specs, you know?

> 

Ektanoor


--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Stephen Smalley]

As I mentioned earlier, the LIDS FAQ itself uses the term
"mandatory access control" to describe some of the LIDS features.
The LIDS ACLs and capability assignments are administratively-defined,
so a system-wide security policy can be enforced on the granting of file
accesses and capabilities.  The protections against killing certain
processes in LIDS are a limited form of the general process-to-process
signal access controls in SELinux.

I'm not sure what you mean when you say that SELinux MAC is controlled
from a central point and that LIDS is not controlled from any center.  If
you are referring to the security server, keep in mind that the security
server is merely a subsystem in the kernel that reads the policy
configuration from a local file during startup (or during subsequent
policy reloads). The lack of an equivalent to the security server in LIDS
is simply a reflection of the fact that LIDS does not try to provide
flexible support for security policies.  But both systems allow different
policies to be defined for different machines if desired.

I'm also not sure what you mean by your discussion of untrusted
vs. trusted environments.  The mandatory access controls of SELinux
are quite useful for limiting the damage that can be caused by
flawed or malicious applications and for supporting different
levels of trust among users.  So SELinux should be quite useful
in the same environments where LIDS is useful.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com




--
You have received this message because you are subscribed to the selinux 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.

Re: lids

[Pedro Rosa]

Stephen Smalley wrote:

> As I mentioned earlier, the LIDS FAQ itself uses the term
> "mandatory access control" to describe some of the LIDS features.
> The LIDS ACLs and capability assignments are administratively-defined,
> so a system-wide security policy can be enforced on the granting of file
> accesses and capabilities.  The protections against killing certain
> processes in LIDS are a limited form of the general process-to-process
> signal access controls in SELinux.

I didn't read the FAQ. Maybe LIDS claims or tries to support or messes 
with the MAC term.
However let's note that inside the code there are no primary references 
to a MAC architecture. Well I noted only a clear mandatory policy and 
which is giving users the chance to modify some LIDS options, including 
turining it off. But I don't see clearly a server or daemon doing the 
big job controling these "rights".

> 
> 
> I'm not sure what you mean when you say that SELinux MAC is controlled
> from a central point and that LIDS is not controlled from any center.  If
> you are referring to the security server, keep in mind that the security
> server is merely a subsystem in the kernel that reads the policy
> configuration from a local file during startup (or during subsequent
> policy reloads). The lack of an equivalent to the security server in LIDS
> is simply a reflection of the fact that LIDS does not try to provide
> flexible support for security policies.  But both systems allow different
> policies to be defined for different machines if desired.

But, as far as  could understand from the selinux docs, this subsystem 
is an independent identity with a proper set of functions and which can 
be local or expanded to a network. This "automata" is a very specialized 
unit that not only sets but also controls the permissions. On the other 
way LIDS is more a set of kernel "anchors" that permit or restrict the 
use of certain resources. 

> 
> 
> I'm also not sure what you mean by your discussion of untrusted
> vs. trusted environments.  The mandatory access controls of SELinux
> are quite useful for limiting the damage that can be caused by
> flawed or malicious applications and for supporting different
> levels of trust among users.  So SELinux should be quite useful
> in the same environments where LIDS is useful.

Well I really don't think so. You are quite correct in noting the fact 
that SELinux is useful to limit possible damages. But note that this 
kind of architecture is in fact quite vulnerable in places where 
malicious users are present or there are serious flaws in the 
communication infrastructure. Besides guarantees against malicious 
applications fall in the measure of how this environment may allow their 
presence. One of NSA docs exactly referred to this point. From what I 
could get, SELinux is only useful when you have an have a secured 
office, do a good care to check apps and users and have some good 
firewall system to protect the LANs. In this case SELinux complements 
this environment by distributing resources according to policy uses, and 
caring for their limited use, in face of a control system. Anyway 
SELinux is not strong enough to avoid systematic attacks or covert 
agents or a bugged network. Besides, it has not a serious system of 
countermeasures and accounting beyond its access policies.

On the other side LIDS is weaker on MACs and ACLs. Well, as an example 
among many, we see that LIDS does not demand any changes on user 
programs, while SELinux highly recomends/demands such changes to be 
made.  Besides it possesses less ideological congruence in its parts. In 
a office environment it is of less use than SELinux. Personally I would 
shoot the first LIDS user, if my office would be made of a SELinux 
environment. Surely I wouldn't risk the use of LIDS as it is quite hard 
to use it in a large net with many users. If I can have some control on 
the users and everything that sorrounds their workstations then I would 
opt for SELinux as it fits for the task.

However if the user has to travel somewhere and carries a notebook, then 
I would surely put LIDS on it, and NOT SELinux. Apart of being weaker, 
in a worst case scenario, the LIDS machine has the potential of giving 
some information about a break-in. However, in the same situation, a 
SELinux may pass well away and carry back a danger to the trusted 
environment. Also I would risk the use of  LIDS in such environments 
like student classes, even if there are hundreds of users and it would 
be quite hard to control the network. However it is very hard to trust 
such net. Frankly, it is impossible to be trusted if you give some 
freedom to users. So one should not only care about permissions but also 
to get a record on activities that may put these permissions in danger.

Anyway I think both systems are well in their infancy. SELinux looks 
more solid due to the detailed overwork and documented design. But the 
tight  conception makes it loose a few points to LIDS as this one is 
relatively more broad and flexible in its tasks.

Ektanoor

> 
> 
> --
> Stephen D. Smalley, NAI Labs
> sds@tislabs.com
> 
> 
> 
> 
> 



--
You have received this message because you are subscribed to the selinux 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.

Re: [selinux] Re: lids

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Pedro Rosa a következőeket írta:
> > 
> > I'm also not sure what you mean by your discussion of untrusted
> > vs. trusted environments.  The mandatory access controls of SELinux
> > are quite useful for limiting the damage that can be caused by
> > flawed or malicious applications and for supporting different
> > levels of trust among users.  So SELinux should be quite useful
> > in the same environments where LIDS is useful.
> 
> Well I really don't think so. You are quite correct in noting the fact 
> that SELinux is useful to limit possible damages. But note that this 
> kind of architecture is in fact quite vulnerable in places where 
> malicious users are present or there are serious flaws in the 
> communication infrastructure. Besides guarantees against malicious 
> applications fall in the measure of how this environment may allow their 
> presence. One of NSA docs exactly referred to this point. From what I 
> could get, SELinux is only useful when you have an have a secured 
> office, do a good care to check apps and users and have some good 
> firewall system to protect the LANs. In this case SELinux complements 

The mandatory access control policies specifically target the case
where malicious users/malware present. Please read any introductory
paper on the Bell-LaPadula or any other MAC modell.
Please do not get confused about the fact that the selinux docs
explicitly emphasize the well-known fact, that the security of _any_
system cannot be guaranteed without some measures external to the
technical tools of the system. A clearly stated policy, and
definition of user procedures comes to mind as the most important
items. Furthermore _any_ security control is based on assumptions. The
fact that these assumptions are held also should be guaranteed
by measures external to the system.
The above holds for LIDS, even if these facts are not emphasized
in its docs.

> this environment by distributing resources according to policy uses, and 
> caring for their limited use, in face of a control system. Anyway 
> SELinux is not strong enough to avoid systematic attacks or covert 
> agents or a bugged network. Besides, it has not a serious system of 
> countermeasures and accounting beyond its access policies.

The theory behind selinux is very strong. It does not target every
functional requirement you can think of or read in the CC, but it
clearly goes in that direction, in a very planned manner.

Please note that I am not talking about the actual implementation
of these tools, because I am not yet familiar enough with any of them.

-- 
GNU GPL: csak tiszta forrásból

--
You have received this message because you are subscribed to the selinux 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.