have you seen spfx2.c?

have you seen spfx2.c?

[0x]

have you seen the security module
http://packetstorm.decepticons.org/linux/security/spfx2.c ?


--
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: have you seen spfx2.c?

[Grant Bayley]

What I don't understand with Linux users is the endless desire to
prevent broken things by patching around them in the kernel.

Why not concentrate on cleaning up the userland apps in Linux in such a
way that they're not overflowable in the first place?

No broken [suid | sgid | priviliged uid daemon ] userland apps means you
have a substantially better chance of keeping a system secure without all
the sleight of hand that lkms typically pull to prevent something bad from
happening.

Think about this logic for a second, then check out:

	http://www.openwall.com/Owl/

Grant

On Sun, 2 Dec 2001 0x@bk.ru wrote:

>
> have you seen the security module
> http://packetstorm.decepticons.org/linux/security/spfx2.c ?


--
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: have you seen spfx2.c?

[Stephen Smalley]

On Sun, 2 Dec 2001, Grant Bayley wrote:

> What I don't understand with Linux users is the endless desire to
> prevent broken things by patching around them in the kernel.
>
> Why not concentrate on cleaning up the userland apps in Linux in such a
> way that they're not overflowable in the first place?
>
> No broken [suid | sgid | priviliged uid daemon ] userland apps means you
> have a substantially better chance of keeping a system secure without all
> the sleight of hand that lkms typically pull to prevent something bad from
> happening.

It sounds like you are also arguing against the approach of SELinux, which
adds mandatory access controls to the kernel that can confine user
programs and system servers to the minimum amount of privilege they
require to do their jobs.  While it is certainly good to work on
eliminating flaws from privileged applications, you're unlikely to
eliminate all of the flaws in all of the privileged applications for all
time.  Without mandatory access controls in the kernel, flawed
applications will still be able to easily cause failures in system
security.  Additionally, eliminating flaws from privileged applications
doesn't help with other problems solved by mandatory access controls,
e.g. confining malicious code, providing strong separation of processes
and data based on confidentiality and integrity requirements, protecting
applications against bypass or tampering.

The need for MAC is discussed further in the published papers about
SELinux and the background papers, all available on the web site.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.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: have you seen spfx2.c?

[Dale Amon]

On Sun, Dec 02, 2001 at 02:14:35PM +1100, Grant Bayley wrote:
> 
> What I don't understand with Linux users is the endless desire to
> prevent broken things by patching around them in the kernel.
> 
> Why not concentrate on cleaning up the userland apps in Linux in such a
> way that they're not overflowable in the first place?
> 
> No broken [suid | sgid | priviliged uid daemon ] userland apps means you
> have a substantially better chance of keeping a system secure without all
> the sleight of hand that lkms typically pull to prevent something bad from
> happening.
> 
> Think about this logic for a second, then check out:
> 
> 	http://www.openwall.com/Owl/
> 

The logic fails in real life. There is one kernel,
written by experts. There are tens if not hundreds of 
thousands of apps, written by novices, experts, people
who listen, people who don't listen, supported, 
unsupported...

An environment that defends against userland lameness
is the only solution.

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.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: have you seen spfx2.c?

[Russell Coker]

On Mon, 3 Dec 2001 16:16, Dale Amon wrote:
> The logic fails in real life. There is one kernel,
> written by experts. There are tens if not hundreds of
> thousands of apps, written by novices, experts, people
> who listen, people who don't listen, supported,
> unsupported...

This thread shouldn't be dragging on, but I feel that there are a couple of 
crucial points that are being missed.

Firstly there is the issue of multiple levels of protection.  I have three 
locked doors leading to my apartment which I believe gives me significant 
benefits over having only a single locked door.  When I setup co-located 
servers I run packet filters on the servers and also get the ISP to put a 
firewall in place.  Similarly I expect that having two sub-systems trying to 
achieve the same security result by different methods (daemons that don't 
have security holes and a kernel to limit the access the daemons get) is 
worth-while.

The next issue is that even good programmers make mistakes occasionally.  I 
consider the author of Postfix to be one of the best programmers in the 
world, he really knows how to code and really knows security.  In spite of 
this I plan to limit the access Postfix gets to my system, even the best 
programmers can make mistakes occasionally, and besides the person who 
compiled it could have done something wrong.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page


--
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.