All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [ISN] Music file flaws could threaten traders
       [not found] <Pine.LNX.4.44.0212190257480.19905-100000@idle.curiosity.org>
@ 2002-12-19 22:07 ` Russell Coker
  2002-12-19 22:41   ` Paul Krumviede
                     ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Russell Coker @ 2002-12-19 22:07 UTC (permalink / raw)
  To: selinux

This type of thing could affect Linux in the same way as it affects Windows.

Currently we have "risky" programs such as netscape, games, and IRC clients in 
their own domains that have types for read-only and for read-write files (and 
no ability to run gpg or other important programs).

The problem about doing the same for audio/video programs such as players for 
avi, mp3, and vob files is that their typical use involves downloading files 
from the net to play immediately so that denying them read access to 
user_home_t files will give a large decrease in functionality.  I believe 
that there are two major categories of SE Linux users, those who will never 
run such A/V programs on Linux, and those who won't use any security software 
that gets in the way of their entertainment.

So I think that having a domain for A/V programs such as $1_av_t that has read 
access to $1_home_t and can create files with the type $1_home_av_t may not 
be as tightly secured as we might like, but the people who are concerned 
about that won't use it anyway.

On Thu, 19 Dec 2002 09:58, InfoSec News wrote:
> http://news.com.com/2100-1001-978403.html?tag=fd_top
>
> By Robert Lemos
> Staff Writer, CNET News.com
> December 18, 2002, 5:12 PM PT
>
> A security firm on Wednesday warned that people using Windows XP or
> popular music player WinAmp could fall prey to a vulnerability,
> enabling a modified music file to take control of a person's PC.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-19 22:07 ` [ISN] Music file flaws could threaten traders Russell Coker
@ 2002-12-19 22:41   ` Paul Krumviede
  2002-12-20  6:45     ` Russell Coker
  2002-12-20  0:16   ` Brian May
  2002-12-20  9:15   ` Tom
  2 siblings, 1 reply; 8+ messages in thread
From: Paul Krumviede @ 2002-12-19 22:41 UTC (permalink / raw)
  To: Russell Coker, selinux

--On Thursday, 19 December, 2002 23:07 +0100 Russell Coker 
<russell@coker.com.au> wrote:

> This type of thing could affect Linux in the same way as it affects
> Windows.

i'm not so sure. the bugtraq posting about the windows XP bug
indicated that it could be exploited even without downloading
a file to the user's computer. if using explorer, the file had to be
on the local machine, but didn't need to be "played" to allow
an exploit. i don't think that either case is relevant to selinux
(but would like to know if i'm wrong).

i haven't looked at the winamp report yet.

-paul

> Currently we have "risky" programs such as netscape, games, and IRC
> clients in  their own domains that have types for read-only and for
> read-write files (and  no ability to run gpg or other important programs).
>
> The problem about doing the same for audio/video programs such as players
> for  avi, mp3, and vob files is that their typical use involves
> downloading files  from the net to play immediately so that denying them
> read access to  user_home_t files will give a large decrease in
> functionality.  I believe  that there are two major categories of SE
> Linux users, those who will never  run such A/V programs on Linux, and
> those who won't use any security software  that gets in the way of their
> entertainment.
>
> So I think that having a domain for A/V programs such as $1_av_t that has
> read  access to $1_home_t and can create files with the type $1_home_av_t
> may not  be as tightly secured as we might like, but the people who are
> concerned  about that won't use it anyway.
>
> On Thu, 19 Dec 2002 09:58, InfoSec News wrote:
>> http://news.com.com/2100-1001-978403.html?tag=fd_top
>>
>> By Robert Lemos
>> Staff Writer, CNET News.com
>> December 18, 2002, 5:12 PM PT
>>
>> A security firm on Wednesday warned that people using Windows XP or
>> popular music player WinAmp could fall prey to a vulnerability,
>> enabling a modified music file to take control of a person's PC.
>
> --
> 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.
>



--
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] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-19 22:07 ` [ISN] Music file flaws could threaten traders Russell Coker
  2002-12-19 22:41   ` Paul Krumviede
@ 2002-12-20  0:16   ` Brian May
  2002-12-20  7:23     ` Russell Coker
  2002-12-20  9:15   ` Tom
  2 siblings, 1 reply; 8+ messages in thread
From: Brian May @ 2002-12-20  0:16 UTC (permalink / raw)
  To: Russell Coker; +Cc: selinux

On Thu, Dec 19, 2002 at 11:07:20PM +0100, Russell Coker wrote:
> On Thu, 19 Dec 2002 09:58, InfoSec News wrote:
> > http://news.com.com/2100-1001-978403.html?tag=fd_top
> >
> > By Robert Lemos
> > Staff Writer, CNET News.com
> > December 18, 2002, 5:12 PM PT
> >
> > A security firm on Wednesday warned that people using Windows XP or
> > popular music player WinAmp could fall prey to a vulnerability,
> > enabling a modified music file to take control of a person's PC.

I think it should be possible to write a program that checks to source
file, makes sure it is valid and doesn't contain any errors or other
potentially dangerous stuff (eg. a multimedia tag with too much data, as
per article), and then relabels it with a file label that allows the
user to freely use that file.

Even better, this program could be generalized to automatically
detect the format, and take appropriate action (eg. virus scanner
for executables, MP3 valididator for MP3 files, etc).

(then again, I am not entirely familiar with MP3 or PNG formats, they
weren't around when I did my University course).
--
Brian May <bam@snoopy.apana.org.au>

--
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] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-19 22:41   ` Paul Krumviede
@ 2002-12-20  6:45     ` Russell Coker
  0 siblings, 0 replies; 8+ messages in thread
From: Russell Coker @ 2002-12-20  6:45 UTC (permalink / raw)
  To: Paul Krumviede, selinux

On Thu, 19 Dec 2002 23:41, Paul Krumviede wrote:
> <russell@coker.com.au> wrote:
> > This type of thing could affect Linux in the same way as it affects
> > Windows.
>
> i'm not so sure. the bugtraq posting about the windows XP bug
> indicated that it could be exploited even without downloading
> a file to the user's computer. if using explorer, the file had to be
> on the local machine, but didn't need to be "played" to allow
> an exploit. i don't think that either case is relevant to selinux
> (but would like to know if i'm wrong).

KDE supports creating "thumbnail" pictures to represent different types of 
files on the desktop and could also be vulnerable to "list a directory and 
have some code executed" type bugs.

The problem with KDE is that everything seems to be run from one process that 
just forks off copies of itself and mmap's executables (thus avoiding 
automatic domain transitions).

I think that this is relevant to people who are writing SE Linux policy.  It 
does not affect Linux, yet, AFAIK...  But sometimes it's best to lock down 
things that look dangerous rather than waiting for proof that they are 
dangerous (you never get absolute proof that anything is safe).

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-20  0:16   ` Brian May
@ 2002-12-20  7:23     ` Russell Coker
  2002-12-20 23:46       ` Brian May
  0 siblings, 1 reply; 8+ messages in thread
From: Russell Coker @ 2002-12-20  7:23 UTC (permalink / raw)
  To: Brian May; +Cc: selinux

On Fri, 20 Dec 2002 01:16, Brian May wrote:
> I think it should be possible to write a program that checks to source
> file, makes sure it is valid and doesn't contain any errors or other
> potentially dangerous stuff (eg. a multimedia tag with too much data, as
> per article), and then relabels it with a file label that allows the
> user to freely use that file.

If that is the approach that you want then why not just audit the source code 
to all the programs that use such files?

Surely auditing source code to applications is easier than writing 
virus-scanners for every type of file that MIGHT break some buggy program 
somewhere and cause a security hole.

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-19 22:07 ` [ISN] Music file flaws could threaten traders Russell Coker
  2002-12-19 22:41   ` Paul Krumviede
  2002-12-20  0:16   ` Brian May
@ 2002-12-20  9:15   ` Tom
  2 siblings, 0 replies; 8+ messages in thread
From: Tom @ 2002-12-20  9:15 UTC (permalink / raw)
  To: Russell Coker; +Cc: selinux

On Thu, Dec 19, 2002 at 11:07:20PM +0100, Russell Coker wrote:
> The problem about doing the same for audio/video programs such as players for 
> avi, mp3, and vob files is that their typical use involves downloading files 
> from the net to play immediately so that denying them read access to 
> user_home_t files will give a large decrease in functionality.  I believe 
> that there are two major categories of SE Linux users, those who will never 
> run such A/V programs on Linux, and those who won't use any security software 
> that gets in the way of their entertainment.

My preferred solution would be to handle this much like in old BBS
days. Any file downloaded from the net, no matter how, should be
labeled with a special "untrusted download" type first. It could then
either be relabeled after checking (for virii, content correctness or
whatever) or the player could be run in a domain that allows absolute
minimum access only.

This can be implemented in one of two ways:

a) by modifying any programs downloading files
b) by making downloads only  to a special download directory
   and using file_auto_trans there.
   

The better/easier b) requires a little discipline from the user since
netscape et al will need write access to other directories (e.g. /tmp)
so he _could_ in theory save his stuff there.


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-20  7:23     ` Russell Coker
@ 2002-12-20 23:46       ` Brian May
  2002-12-21 18:20         ` Russell Coker
  0 siblings, 1 reply; 8+ messages in thread
From: Brian May @ 2002-12-20 23:46 UTC (permalink / raw)
  To: Russell Coker; +Cc: selinux

On Fri, Dec 20, 2002 at 08:23:55AM +0100, Russell Coker wrote:
> On Fri, 20 Dec 2002 01:16, Brian May wrote:
> > I think it should be possible to write a program that checks to source
> > file, makes sure it is valid and doesn't contain any errors or other
> > potentially dangerous stuff (eg. a multimedia tag with too much data, as
> > per article), and then relabels it with a file label that allows the
> > user to freely use that file.
> 
> If that is the approach that you want then why not just audit the source code 
> to all the programs that use such files?

That would be the best long term solution.

After it, it isn't really the files that are at fault, it is the
application that is at fault.

If this invalid file was created accidently (eg. due to buggy
software or data curruption), you wouldn't want it crashing you
applications either.

Which means were going around in circles, and I am arguing
your case for running AV programs in a seperate domain, until
they can be audited at least. Oh well...

> Surely auditing source code to applications is easier than writing
> virus-scanners for every type of file that MIGHT break some buggy
> program somewhere and cause a security hole.

Not so much a virus-scanner, more a "fsck"/validator that works on data
files rather then harddisk images. I would be surprised if such a
program doesn't already exist, there must be some program to ensure
output MP3 files are consistant with the MP3 standard (whether it is
free software or not though is another matter).
--
Brian May <bam@snoopy.apana.org.au>

--
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] 8+ messages in thread

* Re: [ISN] Music file flaws could threaten traders
  2002-12-20 23:46       ` Brian May
@ 2002-12-21 18:20         ` Russell Coker
  0 siblings, 0 replies; 8+ messages in thread
From: Russell Coker @ 2002-12-21 18:20 UTC (permalink / raw)
  To: Brian May; +Cc: selinux

On Sat, 21 Dec 2002 00:46, Brian May wrote:
> > If that is the approach that you want then why not just audit the source
> > code to all the programs that use such files?
>
> That would be the best long term solution.

In which case OpenBSD may be more suitable to your needs than SE Linux.  
Considered working on the Debian OpenBSD project?

Don't take this as some sort of sarcastic comment.  I think that the OpenBSD 
project is doing some good things and that Debian OpenBSD is a worthy 
project.  I encourage people to work on such things if that interests them.

> Which means were going around in circles, and I am arguing
> your case for running AV programs in a seperate domain, until
> they can be audited at least. Oh well...

;)

> > Surely auditing source code to applications is easier than writing
> > virus-scanners for every type of file that MIGHT break some buggy
> > program somewhere and cause a security hole.
>
> Not so much a virus-scanner, more a "fsck"/validator that works on data
> files rather then harddisk images. I would be surprised if such a
> program doesn't already exist, there must be some program to ensure
> output MP3 files are consistant with the MP3 standard (whether it is
> free software or not though is another matter).

I'm sure that there are "lint" type programs for many different types of file.  
However they are generally aimed at ensuring that the files are usable not 
that they are not going to cause an exploit.  Also it is quite possible for a 
file to comply with all standards and still break an application!  Many 
buffer overflow exploits are of such a nature.

But this would be an interesting topic for research.  Are you planning on 
getting a second Ph.D?

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-12-21 18:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.44.0212190257480.19905-100000@idle.curiosity.org>
2002-12-19 22:07 ` [ISN] Music file flaws could threaten traders Russell Coker
2002-12-19 22:41   ` Paul Krumviede
2002-12-20  6:45     ` Russell Coker
2002-12-20  0:16   ` Brian May
2002-12-20  7:23     ` Russell Coker
2002-12-20 23:46       ` Brian May
2002-12-21 18:20         ` Russell Coker
2002-12-20  9:15   ` Tom

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.