linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Fredrik Tolf <fredrik@dolda2000.cjb.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: PTY DOS vulnerability?
Date: Tue, 1 Jul 2003 07:15:30 -0500	[thread overview]
Message-ID: <03070107153001.01125@tabby> (raw)
In-Reply-To: <1057008994.17589.40.camel@dhcp22.swansea.linux.org.uk>

On Monday 30 June 2003 16:36, Alan Cox wrote:
> On Llu, 2003-06-30 at 22:31, Fredrik Tolf wrote:
> > That is true, though, of course. Stupid me not to think about
> > that. However, that means that an administrator who could find
> > himself being under such an attack might not think about it
> > either. Also, from the outside, the ssh client just does
> > nothing, making it look as if the server is unresponsive. Of
> > course, the exact error is logged to the server's syslog, but if
> > you can't view it, then you won't know about it.
> >
> > So all in all, do you think I should implement a per-user
> > resource limit on PTYs?
>
> There are a whole collection of things that would benefit from that kind
> of management - go for it but make it possible to add other stuff too

In thinking about that...

I would suggest a "resource allocation daemon", where resource is defined
to be non-kernel objects - devices mostly... ptys /dev/tape unmounted disks
removable media, specific files (not sure how to explain this one though, but
controlling access to specified fifo's, memory mapped files? how about 
printer queues...)

Anything that gets defined as a system wide resource that users may access, 
but exist as external (to the kernel) objects. It would need some kind of 
kernel interface, but the access control would be defined outside the kernel.

The most the kernel would need is a "resource controlled by" and "resource 
allocated to" identification so that the appropriate daemon could be invoked
(I do see a possibility for multiple resource allocation daemons).

  reply	other threads:[~2003-07-01 12:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-30 14:18 PTY DOS vulnerability? Fredrik Tolf
2003-06-30 17:55 ` Alan Cox
2003-06-30 21:31   ` Fredrik Tolf
2003-06-30 21:36     ` Alan Cox
2003-07-01 12:15       ` Jesse Pollard [this message]
2003-07-01 13:41       ` Timothy Miller
2003-07-01  6:22 ` Oleg Drokin
2003-07-01 11:57 ` Jesse Pollard
2003-07-01 19:53   ` Helge Hafting
2003-07-02  6:42     ` Paul Rolland
2003-07-03  1:14     ` Jesse Pollard
2003-07-03  1:52       ` H. Peter Anvin
2003-07-08 23:11 Clayton Weaver
2003-07-09 10:08 ` Svein Ove Aas

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=03070107153001.01125@tabby \
    --to=jesse@cats-chateau.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=fredrik@dolda2000.cjb.net \
    --cc=linux-kernel@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 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).