linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Peter Dolding" <oiaohm@gmail.com>
To: david@lang.hm
Cc: davecb@sun.com, rmeijer@xs4all.nl,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	capibara@xs4all.nl, "Eric Paris" <eparis@redhat.com>,
	"Theodore Tso" <tytso@mit.edu>, "Rik van Riel" <riel@redhat.com>,
	linux-security-module@vger.kernel.org,
	"Adrian Bunk" <bunk@kernel.org>,
	"Mihai Don??u" <mdontu@bitdefender.com>,
	linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
	"Pavel Machek" <pavel@suse.cz>,
	"Arjan van de Ven" <arjan@infradead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning
Date: Mon, 18 Aug 2008 12:33:28 +1000	[thread overview]
Message-ID: <e7d8f83e0808171933r25edc712pf656e09fbd387cf3@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0808171839380.12859@asgard.lang.hm>

On Mon, Aug 18, 2008 at 11:44 AM,  <david@lang.hm> wrote:
> On Mon, 18 Aug 2008, Peter Dolding wrote:
>
>> On Mon, Aug 18, 2008 at 7:17 AM, David Collier-Brown <davecb@sun.com>
>> wrote:
>>>
>>> Peter Dolding wrote:
>>>>
>>>> Currently if we have a unknown infection on a  windows partition that
>>>> is been shared by linux the scanner on Linux cannot see that the
>>>> windows permissions has been screwed with.   OS with badly damaged
>>>> permissions is a sign of 1 of three things.  ...
>>>
>>> It's more likely that the files will reside on Linux/Unix under
>>> Samba, and so the permissions that Samba implements will be the ones
>>> that the virus is trying to mess up.  These are implemented in
>>> terms of the usual permission bits, plus extended attributes/ACLs.
>>> Linux systems mounting Windows filesystems are somewhat unusual (;-))
>>>
>> More desktop use of Linux more cases of ntfs and fat mounted under
>> Linux.  Funny enough linux mounting windows file systems is 100
>> percent normal for most Ubuntu users so there are a lot of them out
>> there doing it.   I am future looking there are other filesystems
>> coming with there own issues as well.
>
> but what you are missing is that when they are mounted under linux it
> doesn't matter what hidden things the other OS may access, all that matters
> is what Linux sees. If Linux doesn't see something it can't serve it out to
> those other OSs.
>
> those 'hidden things' would only matter if you were trying to use linux to
> scan a drive and bless it for another system to then mount locally. If we
> aren't trying to defend against that (and I don't hear anyone other then you
> saying we should) then we don't need to worry about such things.
>
> If we were trying to make the drive safe for all other OSs to mount
> directly, then mearly seeing everything isn't enough, you would have to be
> able to fully duplicate how the other OS interprets the things you are
> seeing, and know all vunerabilities that arise from all possible
> interpretations. I don't think that's possible (and I don't think it would
> be possible even if the source for all those other OSs were available)
>
Matters directly for 2 cases to the Linux system itself.

First case HIDS spotting alteration to something like if someone
places signature files on a NTFS partition for some reason when it was
placed there it was X permission now its Y better inform the user that
this has happened.     Without being able to see the disk permissions
this could be missed due to no translation of permissions to vfs.  We
have Ubuntu users in this mix they will put it on NTFS if they are low
of disk space.

Second case is file system mount options changing the files that are
displayed in vfs so a full partition scan by a scanner running in
Linux is a full disk scan not some files missed here or there due to
hidden permissions and processing in the file system driver.

Next bits I think is not understanding how some defence tech works and
lack of experience in forensics.

Full hids monitoring does not depend on known how the OS will
interpret it picking up that month after month something has never
been changed and then all of a sudden something is changed to alert
you to look deeper.   Its more of a warning bell so that works without
ever understanding 100 percent how the permissions work.  When
compared to other machines setup in the same kind of way more fine
defects can turn up.  Same software Same applications same profiles
sent from server should be a 99 percent match other than SID number
being different.  Most of that variation from each other should turn
up in the first week of usage.   HIDS is basically anything stepping
out side normal go off.

Doing forensic recoveries on things I have learnt yes you can
duplicate how a OS will interpret its disk permissions.   Complexity
is directly linked to how tidy the OS's permission system is.
Windows is surprisingly not that bad.  Linux and BSD are level 10
pricks due to the fact config file over here may completely provide
access where disk permissions say no then you have the LSM permissions
to over lay.   So its a pain in tail to duplicate how some OS's would
interpret it but 100 percent do able if you know the software on top
even how that reacts is predictable without running it.   Forensic
working out a attack you do it.  Since running the OS only makes the
threat active worse let the threat cover its trail.   Lot of white
listing is performed in the process to confirm that programs have not
been messed with.  So there configuration files processing can be
trusted.  Its simply another myth that it cannot be done.  Off-line
scanning can be done if the scanner is setup for it yes more complex
process having to read stuff like the windows registry that is poorly
documented.   For fully documented OS's 100 its nothing more than
processing time.  Complete work out of course need the applications on
top that is of course documentation of operation again.   So no
magical non understandable stuff here.

Peter Dolding.

  reply	other threads:[~2008-08-18  2:33 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-15 12:22 [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning Rob Meijer
2008-08-15 13:27 ` Peter Dolding
2008-08-15 17:31   ` david
2008-08-16  3:57     ` Peter Dolding
2008-08-16  4:09       ` Arjan van de Ven
2008-08-16  5:19         ` Peter Dolding
2008-08-16  9:39           ` Theodore Tso
2008-08-16 11:38             ` Peter Dolding
2008-08-16 15:17               ` Theodore Tso
2008-08-17  7:49                 ` Peter Dolding
2008-08-17  8:58                   ` david
2008-08-18  0:11                     ` Peter Dolding
2008-08-18  0:32                       ` david
2008-08-18  1:20                         ` Peter Dolding
2008-08-18 10:54                       ` douglas.leeder
2008-08-18 13:40                         ` Peter Dolding
2008-08-16  5:35         ` Valdis.Kletnieks
2008-08-16  7:27           ` david
     [not found]         ` <alpine.DEB.1.10.0808152115210.12859@asgard.lang.hm>
2008-08-16  9:28           ` Alan Cox
2008-08-16 10:14             ` david
2008-08-17 21:17       ` David Collier-Brown
2008-08-18  1:33         ` Peter Dolding
2008-08-18  1:44           ` david
2008-08-18  2:33             ` Peter Dolding [this message]
2008-08-15 14:18 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2008-08-17 10:33 Rob Meijer
2008-08-17 10:46 ` david
2008-08-17 21:58   ` Pavel Machek
2008-08-17 22:30     ` david
2008-08-15 10:10 Rob Meijer
2008-08-15 11:02 ` Alan Cox
2008-08-13 12:56 [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Pavel Machek
2008-08-13 13:52 ` tvrtko.ursulin
2008-08-14 12:54   ` Pavel Machek
2008-08-14 18:37     ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-14 22:39       ` Pavel Machek
2008-08-15  0:00         ` Rik van Riel
2008-08-15  0:43           ` Theodore Tso
2008-08-15  1:02             ` Rik van Riel
2008-08-15  3:00             ` Eric Paris
2008-08-15  5:22               ` david
2008-08-15  5:33                 ` david
2008-08-15  5:38                   ` david
2008-08-17 22:14                 ` Pavel Machek
2008-08-17 22:12               ` Pavel Machek
2008-08-17 22:47                 ` david
2008-08-17 22:58                   ` Pavel Machek
2008-08-17 23:24                     ` david
2008-08-18  0:00                     ` Casey Schaufler
2008-08-18  0:17                       ` david
2008-08-18  0:31                         ` Peter Dolding
2008-08-18  0:39                           ` david
2008-08-18  0:42                         ` Casey Schaufler
2008-08-18  0:07                     ` Rik van Riel
2008-08-19 10:41                       ` Pavel Machek
2008-08-15  8:35             ` Alan Cox
2008-08-15 11:35               ` Theodore Tso
2008-08-17 22:10               ` Pavel Machek
2008-08-06  0:51 [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Rik van Riel
2008-08-06 12:10 ` Press, Jonathan
2008-08-06 15:08   ` Theodore Tso
2008-08-06 15:33     ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-06 15:46       ` Rik van Riel
2008-08-06 16:12         ` tvrtko.ursulin
2008-08-06 16:25           ` Rik van Riel
2008-08-06 18:06             ` Eric Paris
2008-08-05 17:38 [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " Arjan van de Ven
2008-08-05 18:04 ` Press, Jonathan
2008-08-05 18:11   ` Greg KH
2008-08-05 18:38     ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Press, Jonathan
2008-08-05 18:54       ` Theodore Tso
2008-08-05 20:37         ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-05 21:14           ` Greg KH
2008-08-05 20:18       ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Greg KH
2008-08-05 20:28         ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-05 20:51           ` Eric Paris
2008-08-05 21:08             ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7d8f83e0808171933r25edc712pf656e09fbd387cf3@mail.gmail.com \
    --to=oiaohm@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=bunk@kernel.org \
    --cc=capibara@xs4all.nl \
    --cc=davecb@sun.com \
    --cc=david@lang.hm \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=malware-list@lists.printk.net \
    --cc=mdontu@bitdefender.com \
    --cc=pavel@suse.cz \
    --cc=riel@redhat.com \
    --cc=rmeijer@xs4all.nl \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).