All of lore.kernel.org
 help / color / mirror / Atom feed
From: jfj <jfj@freemail.gr>
To: linux-ppp@vger.kernel.org
Subject: Re: pppd security
Date: Tue, 19 Sep 2006 12:07:21 +0000	[thread overview]
Message-ID: <450FDD79.9090404@freemail.gr> (raw)
In-Reply-To: <450EBBCE.5030204@freemail.gr>

James Carlson wrote:

>jfj writes:
>  
>
>>The trust model is this: We suppose that malware is running.
>>Suppose from a buffer overflow in libPNG which achieved
>>priviledge escallation to root. It is OK for malware to run but
>>it will not be able to connect to anyone.
>>    
>>
>
>What's the point in that?
>
>If your fix becomes common practice, then attackers will just learn to
>open /dev/kmem and rewrite the bits that are preventing them from
>doing what they need to do.  Or more simply just overwrite a binary
>that has the privileges desired, and exec that.
>
>If your fix doesn't become common practice, then the problem (to a
>large extent) hasn't been solved.
>  
>

In order for this to work is must not be common practice.
I'm trying to secure a very specific system. The logic is that it
will be a custom system where, for example, one must do a
couple of ioctl()s on a socket before it is activated. If the
ioctl()s are known, we've done nothing.

It is based on trying to predict what a malware would
attempt and sabotage it by adding non-standard calls.
Without feedback from the inside, the attackers work
will be quite difficult.

And if the malware tries too many things, it will be
detected sooner or later. (/dev/kmem disabled by
CAP_RAWIO)

Now I'm thinking about getting `struct ppp*` from `struct file*`
in ppp_open() and failing if n_channels is non zero. Sounds reasonable?

jerald


      parent reply	other threads:[~2006-09-19 12:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-18 15:31 pppd security jfj
2006-09-18 16:10 ` James Carlson
2006-09-18 19:39 ` jfj
2006-09-18 19:48 ` James Carlson
2006-09-18 20:29 ` jfj
2006-09-18 20:46 ` James Carlson
2006-09-19 12:07 ` jfj [this message]

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=450FDD79.9090404@freemail.gr \
    --to=jfj@freemail.gr \
    --cc=linux-ppp@vger.kernel.org \
    /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 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.