lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1228347656.6993.31.camel@lappy.spacevs.com>
Date:	Thu, 04 Dec 2008 10:40:56 +1100
From:	Geoffrey McRae <geoff@...idhost.com>
To:	Peter Teoh <htmldeveloper@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Nick Andrew <nick@...k-andrew.net>,
	linux-kernel@...r.kernel.org
Subject: Re: New Security Features, Please Comment

On Thu, 2008-12-04 at 07:27 +0800, Peter Teoh wrote:
> On Thu, Dec 4, 2008 at 7:08 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> >> The children are pre-forked, so the overhead is in the setup... then
> >> when the app recieves a request, it sets the child's uid to the uid of
> >> the website, and then passes the request to the child, which, now, the
> >> child is running as the website owner.
> >
> > But the child process may already have been trojanned by a previous user
> > so it gains you nothing.
> >
> 
> Yes, I thought so too.   The trojanized child, even though most of the
> time unprivileged, can wait for that window of opportunity when its
> privilege is escalated, by polling, and when it received the
> privilege, immediate jump into action.
> 
> Thanks.
> 

Ok, so this is a pretty major flaw of the idea, thats why I put this
concept out there, any suggestions as to how to get around this?
Possibly add some checking to disable certain functions in the child
when the enable_setpresuid function has been called?.

Or save the signal handlers the first time setpresuid is called, and the
next time, restore them so if the child has changed them, they get
re-set back to their initial state?

I know many people are against the idea of adding new functions at will
to the kernel, thats why I am trying to flesh out all the potential
problems and find solutions to them first.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ