SELinux, KDE, and honeypots

SELinux, KDE, and honeypots

[Bill Laut]

(1)  Once I finish cleaning up my gateway/router's policy, I would like to 
migrate my workstation to SELinux so that I can allow Mozilla to run 
Javascripting and/or plugins without the fear of my workstation being 
compromised.  In reading through the archive, it seems the only thing that 
needs to be modified is kdm.  Is this a correct assumption, or should I 
expect it to be more involved than that?

(2)  My earlier encounter with the avc network messages inspired an idea for a 
possible Intrusion Detection System.  For example, consider a typical server 
running Apache, Sendmail, and Qpopper; to which the sysadmin wants to know if 
the server is ever compromised, and if so how was it accomplished.

The idea I had was to create a pseudo-device driver that leverages NetFilter 
to output all traffic from all TCP streams to a user-mode daemon that writes 
the packets for each stream into their own separate disk files (and governing 
the throughput if need be so that the transcribing daemon can keep up with 
the traffic).  If no security violations are reported during the lifetime of 
the TCP stream, then when it is closed the transcript is moved to a directory 
where it remains for some period of time (perhaps for auditing purposes) 
before being routinely deleted.

If, however, any security violations are reported they are recorded into the 
transcript file in sequence with the TCP packets, and then when the stream is 
closed the completed file is moved into a permanent directory for later 
analysis.  

The general idea is that if some hitherto unknown weakness in a daemon is 
exploited, that the transcript file would allow an analyst to speedily 
determine the exploit vector and thereby facilitate patching the exploit.  
Does this idea sound reasonable?  Has someone already done it using SELinux?  
If not, how would you improve it?


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

Re: SELinux, KDE, and honeypots

[Tom]

On Tue, Jul 08, 2003 at 11:03:22PM -0400, Bill Laut wrote:
> (1)  Once I finish cleaning up my gateway/router's policy, I would like to 
> migrate my workstation to SELinux so that I can allow Mozilla to run 
> Javascripting and/or plugins without the fear of my workstation being 
> compromised.  In reading through the archive, it seems the only thing that 
> needs to be modified is kdm.  Is this a correct assumption, or should I 
> expect it to be more involved than that?

Yes, though if I understand correctly, the kdm patch was never actually
tested.

There is a patched wdm available from my website at
http://selinux.lemuria.org

I haven't yet updated it to the most current wdm version, but it works
for me.


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

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

Re: SELinux, KDE, and honeypots

[Russell Coker]

On Wed, 9 Jul 2003 13:03, Bill Laut wrote:
> (1)  Once I finish cleaning up my gateway/router's policy, I would like to
> migrate my workstation to SELinux so that I can allow Mozilla to run
> Javascripting and/or plugins without the fear of my workstation being
> compromised.  In reading through the archive, it seems the only thing that
> needs to be modified is kdm.  Is this a correct assumption, or should I
> expect it to be more involved than that?

Currently there is no usable patch for kdm.  The reason for this is that the 
SE Linux header files do not compile in C++ mode (and kdm is mostly C++).  I 
have been meaning to solve this but haven't had time.

If you can get a basic program compiled in C++ mode (source named file.cpp) 
that can get it's process context and do an execve_secure() then that will be 
99% of the work necessary to get a SE patched kdm.

However kdm is not necessary to run KDE.  You can login at the console and run 
"exec startx", which is what I do now.

> The idea I had was to create a pseudo-device driver that leverages
> NetFilter

Why not just write an application that uses libpcap (tcpdump functionality)?

> to output all traffic from all TCP streams to a user-mode daemon
> that writes the packets for each stream into their own separate disk files

NB  Make sure you have SE Linux policy to make these files append-only.

> If, however, any security violations are reported they are recorded into
> the transcript file in sequence with the TCP packets, and then when the
> stream is closed the completed file is moved into a permanent directory for
> later analysis.

Sounds like an interesting research idea.  It would be intersting to see the 
results of this, it could even make a good paper for a conference such as 
OLS.  I think it would be good if you do this and publish the code under the 
GPL.  Even if you determine that it's not viable in the initial design form 
it will be a good contribution to the code base and a report on it will be a 
good contribution to the knowledge of network security.

If it has been done before with SE Linux then it hasn't been published.  It 
may have been done before with other MAC systems.


PS I didn't see any reference to honeypots in your message, although I guess 
any IDS technology could form part of a honeypot.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: SELinux, KDE, and honeypots

[Russell Coker]

On Wed, 9 Jul 2003 18:20, Tom wrote:
> Yes, though if I understand correctly, the kdm patch was never actually
> tested.

The patch for KDE 3.x was never successfully compiled (or not by me anyway).

For KDE 2.x I was using the patch for quite a long time, and there's no reason 
why you couldn't use it today.  You would need a default_context file in 
addition to the default_contexts file, but that's not a serious problem.

Using wdm to login to KDE is also a good option.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: SELinux, KDE, and honeypots

[Joshua Brindle]

>The idea I had was to create a pseudo-device driver that leverages
NetFilter 
>to output all traffic from all TCP streams to a user-mode daemon that
writes 
>the packets for each stream into their own separate disk files (and
governing 
>the throughput if need be so that the transcribing daemon can keep up
with 
>the traffic).  If no security violations are reported during the
lifetime of 
>the TCP stream, then when it is closed the transcript is moved to a
directory 
>where it remains for some period of time (perhaps for auditing
purposes) 
>before being routinely deleted.

this is sorta offtopic so i'll just quickly say it would be insane to
try and
handle that with netfilter.. you can use libpcap but that would take
decades to review, your best bet is to plug in an IDS like prelude
(www.prelude-ids.org) to monitor tcp traffic for violations. we are
looking
into getting rules written for the prelude log monitor to understand
selinux avc messages so thats a plus (prelude is hybrid ids, that is
net + host ids) so you can monitor network traffic on your router
and host ids (logs, file digests, etc) on your other machines.

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

Re: SELinux, KDE, and honeypots

[Bill Laut]

On Wednesday 09 July 2003 05:26 am, Russell Coker wrote:
> On Wed, 9 Jul 2003 13:03, Bill Laut wrote:
> > (1)  Once I finish cleaning up my gateway/router's policy, [...]
>
> Currently there is no usable patch for kdm.  The reason for this is that
> the SE Linux header files do not compile in C++ mode (and kdm is mostly
> C++).  I have been meaning to solve this but haven't had time.
>
> If you can get a basic program compiled in C++ mode (source named file.cpp)
> that can get it's process context and do an execve_secure() then that will
> be 99% of the work necessary to get a SE patched kdm.
>

I copied Tom's patched xdm source code, and I will use it along with the 
SELinux's modified login program as a template for changing kdm.

>
> However kdm is not necessary to run KDE.  You can login at the console and
> run "exec startx", which is what I do now.
>

True, but that approach struck me as akin to an "invention in progress," as 
opposed to having a finished product.  Additionally, if SELinux ever hopes to 
be widely adopted into the desktop arena, this bit of xdm/kdm/gdm polishing 
has to be done because the end-user community will never accept having to 
type in "exec startx."  So, this is as good a time as any to get it out of 
the way.

>
> > The idea I had was to create a pseudo-device driver that leverages
> > NetFilter
>
> Why not just write an application that uses libpcap (tcpdump
> functionality)?
>

Somewhat pragmatic but also personal aesthetic:  It seems to me that the 
shortest, simplist way to implement this functionality is to patch the TCP 
layer of the stack itself (and not NetFilter--my mistake) to divert all 
packets into and out of the TCP layer through a device driver that copies 
each packet and then queues the copies to its associated "/dev/whatever" 
file, where a user-mode daemon is waiting to read the packets from 
/dev/whatever and write them to disk.

Going this approach would also simplify obtaining the AVC messages, because 
avc could easily be patched as well to accomodate the driver's copying of any 
relevant security violations as avc prepares to send them to the logger.  
This would facilitate bundling all relevant attack data into one convenient 
file for analysis.

(Or, for that matter, I could even send the security data to another PC that's 
a dedicated logger in order to keep it out of reach of the attacker--but now 
I'm getting ahead of myself.)

Also, since this is a first-order experimental project, rather than drag in 
other packages that might otherwise unduly "bloat" it at this stage, I would 
prefer to use an approach that's as straightforward and simple as possible.  
Once completed, and with its lessons learned, I can then look at extending 
the functionality into different directions.  *That* would be the time, imo, 
to consider perhaps embracing libpcap or prelude.

To use a colloquialism, "baby steps."

As for the personal aesthetic, well, it's been awhile since I had a chance to 
do some kernel hacking, and this looked like a really cool hack.  :-)

>
> > to output all traffic from all TCP streams to a user-mode daemon
> > that writes the packets for each stream into their own separate disk
> > files
>
> NB  Make sure you have SE Linux policy to make these files append-only.
>

Noted.  Thank you for the tip.

>
> > If, however, any security violations are reported they are recorded into
> > the transcript file in sequence with the TCP packets, and then when the
> > stream is closed the completed file is moved into a permanent directory
> > for later analysis.
>
> Sounds like an interesting research idea.  It would be intersting to see
> the results of this, it could even make a good paper for a conference such
> as OLS.  I think it would be good if you do this and publish the code under
> the GPL.  Even if you determine that it's not viable in the initial design
> form it will be a good contribution to the code base and a report on it
> will be a good contribution to the knowledge of network security.
>

It's these kinds of proposed tools that have the potential to make SELinux 
even more appealing to the server community, and in the process leverage 
SELinux to an even larger audience.  Namely, imagine offering them something 
that can not only summarily block the hackers, crackers and script kiddies, 
but can also identify -how- they compromised the daemon as quickly as the 
attackers can find its weaknesses.

While I'm thinking about it, is it possible to configure a domain wherein you 
can limit which ports a daemon is allowed to declare as TCP listeners and/or 
which UDP port numbers it is allowed to create?  That would useful for 
detecting BOs.

>
> If it has been done before with SE Linux then it hasn't been published.  It
> may have been done before with other MAC systems.
>

I'll begin this project sometime in early August, as I have committments for 
July.  Per your suggestion I will publish the code under the GPL via 
Sourceforge.

>
> PS I didn't see any reference to honeypots in your message, although I
> guess any IDS technology could form part of a honeypot.
>

You're right; the reference to honeypots was tangential.  What I was thinking 
of was an SELinux server which logs the attack but doesn't impede its 
progress, so that the attacker's ultimate objective can be determined along 
with the vector used to reach it, hence the reference to a honeypot.


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

Re: SELinux, KDE, and honeypots

[Tracy R Reed]

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

On Tue, Jul 08, 2003 at 11:03:22PM -0400, Bill Laut spake thusly:
> needs to be modified is kdm.  Is this a correct assumption, or should I 
> expect it to be more involved than that?

rjc has already offered a good answer to this. kdm isn't easily patched,
use something else or startx.

> The idea I had was to create a pseudo-device driver that leverages NetFilter 
> to output all traffic from all TCP streams to a user-mode daemon that writes 
> the packets for each stream into their own separate disk files (and governing 

I think this is a pretty slick idea. Although I doubt you have to make it
as fancy as a device driver. I would log everything to an external host
and let that external host also do the sniffing. It could save everything
for a certain amount of time before deleting it (I might go for a week
since this box shouldn't get much traffic and gentle probes can be made
over a long period of time before they pick your box as a target or
discover a vulnerability that will allow them to cause an access
violation) and if there was an access violation it could permanently save
all traffic up to that point and any future traffic of any ip that had
communicated with the box within a minute before and after the violation
occurred. Pretty much all of the vulnerabilities I am aware of cause
instantaneous results but if there are some that might cause a time delay
between the network traffic and the access violation  the window can be
widened to an hour or a day or whatever. It just means we'll have more
data to go through but this box should not be receiving much traffic
anyhow.

Oh, and of course you would want to run the box in permissive mode for all
of this so that their exploit can actually work and you can learn
something.

> Does this idea sound reasonable?  Has someone already done it using SELinux?  
> If not, how would you improve it?

I am not aware of anyone having done it either. Kinda wish I had thought
of it actually. :) My suggestions for improvement are above. Sounds like a
very interesting project.

-- 
Tracy Reed      
http://ultraviolet.org

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: SELinux, KDE, and honeypots

[Russell Coker]

On Thu, 10 Jul 2003 04:08, Bill Laut wrote:
> > > The idea I had was to create a pseudo-device driver that leverages
> > > NetFilter
> >
> > Why not just write an application that uses libpcap (tcpdump
> > functionality)?
>
> Somewhat pragmatic but also personal aesthetic:  It seems to me that the
> shortest, simplist way to implement this functionality is to patch the TCP
> layer of the stack itself (and not NetFilter--my mistake) to divert all

Anything that involves significant kernel changes is unlikely to be the 
shortest simplest solution.

libpcap is something that you can get going in a day and which will result in 
nothing worse than the application itself segv'ing if there's a bug.  Kernel 
code will take significantly more time to write and has significantly greater 
potential to break things if there's a bug.

> Going this approach would also simplify obtaining the AVC messages, because
> avc could easily be patched as well to accomodate the driver's copying of
> any relevant security violations as avc prepares to send them to the
> logger. This would facilitate bundling all relevant attack data into one
> convenient file for analysis.

Yes, you can patch the SE code to handle denied messages in a different 
manner.

> As for the personal aesthetic, well, it's been awhile since I had a chance
> to do some kernel hacking, and this looked like a really cool hack.  :-)

There's lots of other useful kernel work that could be done if you are looking 
for kernel projects.

> While I'm thinking about it, is it possible to configure a domain wherein
> you can limit which ports a daemon is allowed to declare as TCP listeners
> and/or which UDP port numbers it is allowed to create?  That would useful
> for detecting BOs.

Yes, you can already do this through the name_bind access in the tcp_socket 
and udp_socket classes.  The default is that the can_network() macro (used by 
everything that accesses the network) grants access to bind to all ports that 
are not specifically mentioned in the policy.

It has been suggested that we change this and only allow certain domains to 
bind to all ports.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: SELinux, KDE, and honeypots

[Bill Laut]

On Wednesday 09 July 2003 06:41 pm, Tracy R Reed wrote:
> On Tue, Jul 08, 2003 at 11:03:22PM -0400, Bill Laut spake thusly:
> > needs to be modified is kdm.  Is this a correct assumption, or should I
> > expect it to be more involved than that?
>
> rjc has already offered a good answer to this. kdm isn't easily patched,
> use something else or startx.
>

I appreciate what you're saying, but if I had to go the startx route it will 
be a burr under my saddle until I finally get kdm patched.  Maybe if I bloody 
my head from banging against it long enough, I'll think otherwise....

>
> > The idea I had was to create a pseudo-device driver that leverages
> > NetFilter to output all traffic from all TCP streams to a user-mode
> > daemon that writes the packets for each stream into their own separate
> > disk files (and governing
>
> I think this is a pretty slick idea. Although I doubt you have to make it
> as fancy as a device driver. I would log everything to an external host
> and let that external host also do the sniffing. It could save everything
> for a certain amount of time before deleting it (I might go for a week
> since this box shouldn't get much traffic and gentle probes can be made
> over a long period of time before they pick your box as a target or
> discover a vulnerability that will allow them to cause an access
> violation) and if there was an access violation it could permanently save
> all traffic up to that point and any future traffic of any ip that had
> communicated with the box within a minute before and after the violation
> occurred. Pretty much all of the vulnerabilities I am aware of cause
> instantaneous results but if there are some that might cause a time delay
> between the network traffic and the access violation  the window can be
> widened to an hour or a day or whatever. It just means we'll have more
> data to go through but this box should not be receiving much traffic
> anyhow.
>

Yes, I agree wth everything you said.  One of the contingencies I'm 
anticipating is something I call (for lack of a better term) a "refractive 
vector."  This is where the attacker slowly, carefully, methodically "cases" 
the target, ever so gently probing here and there, while installing the 
payload piece by piece while looking for a way in, but constantly vigilant to 
see if they've been detected.

Analyzing such refractive vectors can border on thaumatology--especially if 
they've been artfully hidden in deliberately-manufactured "background noise."

This is where large disk drives are a blessing, so that the necessary data are 
not lost over time--which can be one of the attacker's goals.

>
> Oh, and of course you would want to run the box in permissive mode for all
> of this so that their exploit can actually work and you can learn
> something.
>

Exactly.  This is the essence of my tangential labelling this abstraction as a 
honeypot, although if I were professional about it I would scrub all 
identifiable features so that the attacker couldn't fingerprint it as an 
SELinux-based box.  No sense setting a trap if the perp can detect it.

>
> > Does this idea sound reasonable?  Has someone already done it using
> > SELinux? If not, how would you improve it?
>
> I am not aware of anyone having done it either. Kinda wish I had thought
> of it actually. :) My suggestions for improvement are above. Sounds like a
> very interesting project.
>

Thank you.


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

Re: SELinux, KDE, and honeypots

[Bill Laut]

On Wednesday 09 July 2003 10:20 pm, Russell Coker wrote:
> On Thu, 10 Jul 2003 04:08, Bill Laut wrote:
> >
> > Somewhat pragmatic but also personal aesthetic:  It seems to me that the
> > shortest, simplist way to implement this functionality is to patch the
> > TCP layer of the stack itself (and not NetFilter--my mistake) to divert
> > all
>
> Anything that involves significant kernel changes is unlikely to be the
> shortest simplest solution.
>

The pseudo-device driver I'm envisioning is minimally invasive to the affected 
modules for the reasons you cite below.  Everything else is done outside of 
the kernel.  However, your recommendation of libpcap is noted and will be 
seriously considered.

>
> libpcap is something that you can get going in a day and which will result
> in nothing worse than the application itself segv'ing if there's a bug. 
> Kernel code will take significantly more time to write and has
> significantly greater potential to break things if there's a bug.
>

I understand the implications you raise here.  Once upon a time, almost a 
generation ago, I used to write multi-threaded telecommunications drivers for 
the VAX/VMS Operating System.  I fully appreciate the work involved.

>
> > As for the personal aesthetic, well, it's been awhile since I had a
> > chance to do some kernel hacking, and this looked like a really cool
> > hack.  :-)
>
> There's lots of other useful kernel work that could be done if you are
> looking for kernel projects.
>

Unfortunately, as an amateur cryptology enthusiast my plate is nearly full 
with some unrelated projects I'm engaged in.  As those near completion I may 
take you up on your offer.  Hopefully by then I'll be better acquainted with 
SELinux that I could seriously offer to help you with some kernel work.

>
> > While I'm thinking about it, is it possible to configure a domain wherein
> > you can limit which ports a daemon is allowed to declare as TCP listeners
> > and/or which UDP port numbers it is allowed to create?  That would useful
> > for detecting BOs.
>
> Yes, you can already do this through the name_bind access in the tcp_socket
> and udp_socket classes.  The default is that the can_network() macro (used
> by everything that accesses the network) grants access to bind to all ports
> that are not specifically mentioned in the policy.
>

Excellent.  I'm continually impressed with the thoroughness of SELinux.  You 
folks deserve to be proud of your accomplishment.

>
> It has been suggested that we change this and only allow certain domains to
> bind to all ports.
>

That would be prudent, especially for the daemons.  


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