[2.7 "thoughts"] V0.3

[2.7 "thoughts"] V0.3

[Frederick, Fabian]

2.7 "thoughts"
Thanks to Gabor, Stuart, Stephan and others
Don't hesitate to send me more or comment.

Regards,
Fabian

* slab allocation quota
* ntfs full support
* kernel web server (Interfaced to Roman config tool)
* ipc to sysfs
* complete user quota centralization
* Add _responsibilities_ for virtual process tree and possible
relation in oops cases
* Does the whole proc vm stuff root/box relevant ?I don't think
so....Hence, those proc entries deserve security relevant attributes
* Devices should be limited as well against bad usage(floppy defect),
viral activity(netcard rush)...
* Improve kobject model for security, quota rendering
* bind mount support for all general mount options (nodev,ro,noexec etc)
  with SECURE implementation with any (maybe even future) filesystems?
* union mount (possible with option to declare on what fs a new file
  should be created: on fixed ones, random algorithm, on fs with the
  largest free space available etc ...)
* guaranteed i/o bandwidth allocation?
* netfilter's ability to do tricks which OpenBSD can do now with its
  packet filter
* ENBD support in official kernel with enterprise-class 'through the
  network' volume management
* Standard kernel output (Minimum, Full options ...)
* Virtual machine support
* /proc interface alternative to modutils/module-init-tools.
                That is, to have a directory of virtual nodes in /proc
                to provide the functionality of insmod, rmmod, lsmod &
                modprobe would be great -- especially from the viewpoint
                of recue disk images, etc.
* Software RAID 0+1 perhaps?
                A lot of hardware RAID cards support it, why not the
                kernel?  By RAID 0+1 I mean mirror-RAIDing two (or more)
                stripe-RAID arrays.  (Or can this be done already?)
* Transparent Software-RAID for IDE RAID cards...
                This could be done by using the Software RAID
                functionality of the kernel, but making the RAID
                interface transparent, so you only see a /dev/md?
                device, rather than multiple /dev/?da* entries.
* hotplug RAM

Re: [2.7 "thoughts"] V0.3

[Jens Axboe]

On Fri, Oct 10 2003, Frederick, Fabian wrote:
> 2.7 "thoughts"
> Thanks to Gabor, Stuart, Stephan and others
> Don't hesitate to send me more or comment.

Please, do we really have to look at this from now and until 2.7 opens?
If I see more nice "features" from people that are never going to write
them anyways, I think I'll scream.

> * Software RAID 0+1 perhaps?
>                 A lot of hardware RAID cards support it, why not the
>                 kernel?  By RAID 0+1 I mean mirror-RAIDing two (or more)
>                 stripe-RAID arrays.  (Or can this be done already?)

What's wrong with raid X on top of raid Y? IOW, this works perfectly
fine since, hang on, 2.2 + new raid.

-- 
Jens Axboe

Re: [2.7 "thoughts"] V0.3

[John Bradford]

> * kernel web server (Interfaced to Roman config tool)

A Gopher server is much more suited to this - why bother with the
complexity of a web server just to allow remote access to
configuration info?  It also means that the remote device has to be
one that can deal with HTML.

Gopher would easily scale down to devices as simple as mobile phones,
wrist watches, and LCD panels easily, and be usable over a very slow
link.

John.

Re: [2.7 "thoughts"] V0.3

[Rik van Riel]

On Fri, 10 Oct 2003, John Bradford wrote:

> > * kernel web server (Interfaced to Roman config tool)
> 
> A Gopher server is much more suited to this

Also, what good is a Roman config tool if we don't
export ALL of the statistics in roman numerals ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: [2.7 "thoughts"] V0.3

[William Lee Irwin III]

On Fri, Oct 10, 2003 at 09:54:12AM +0200, Frederick, Fabian wrote:
> 2.7 "thoughts"
> Thanks to Gabor, Stuart, Stephan and others
> Don't hesitate to send me more or comment.

Ugh, this is all crackpot wishlist gunk.

How about some goodies backed with real working code, like:

* O(1) proc_pid_statm()
	-- originally by bcrl for 2.4, fwd port maintained by wli
* O(lg(n)) proc_pid_readdir()/proc_task_readdir()
	-- original O(1) proc_pid_readdir() by manfred, rewritten by
	-- wli to use rbtrees for O(lg(n)) seeks into the relevant
	-- lists (walking over empty buckets had overhead)
* 4KB ia32 kernel stacks + irqstacks
	-- original by bcrl, fwd port maintained by dhansen for a
	-- substantial amount of time, now maintained by wli
* ia32 leaf pagetable node cache
	-- wli
* node-local per_cpu areas for ia32 NUMA
	-- wli
* highpmd, analogue of highpte for pmd's
	-- wli. Gets pmd's on node-local mem on ia32 NUMA, and
	-- alleviates a lot of lowmem pressure under heavy
	-- multiprogramming levels on PAE.

Some benchmarks of a patchset including these (and several other things)
are at http://home.earthlink.net/~rwhron/kernel/wli.html, and some ports
of the patch set are at ftp://ftp.kernel.org/people/wli/kernels/

Whatever fantasy may be worth, working code is worth a lot more. I'll
refrain from mentioning prototype-quality patches I'm hacking on atm.


-- wli

Re: [2.7 "thoughts"] V0.3

[Uncle Jens]

What about some type of kernel-based-DRM, where only properly(trusted) signed
binaries can be executed?  For example, I could compile my public key in with
the kernel and it would only run binaries that had been signed by my private
key.  I feel that this would be a great security enhancement and would like to
hear about any issues this may present.
I've searched all over for a project that does something like this and have been
unable to find one.  I'd like to start one up on my own, but lack the kernel
development expertise.

I'm open for any input/flames/etc....


Michael



Quoting "Frederick, Fabian" <Fabian.Frederick@prov-liege.be>:

> 2.7 "thoughts"
> Thanks to Gabor, Stuart, Stephan and others
> Don't hesitate to send me more or comment.
> 
> Regards,
> Fabian
> 
> * slab allocation quota
> * ntfs full support
> * kernel web server (Interfaced to Roman config tool)
> * ipc to sysfs
> * complete user quota centralization
> * Add _responsibilities_ for virtual process tree and possible
> relation in oops cases
> * Does the whole proc vm stuff root/box relevant ?I don't think
> so....Hence, those proc entries deserve security relevant attributes
> * Devices should be limited as well against bad usage(floppy defect),
> viral activity(netcard rush)...
> * Improve kobject model for security, quota rendering
> * bind mount support for all general mount options (nodev,ro,noexec etc)
>   with SECURE implementation with any (maybe even future) filesystems?
> * union mount (possible with option to declare on what fs a new file
>   should be created: on fixed ones, random algorithm, on fs with the
>   largest free space available etc ...)
> * guaranteed i/o bandwidth allocation?
> * netfilter's ability to do tricks which OpenBSD can do now with its
>   packet filter
> * ENBD support in official kernel with enterprise-class 'through the
>   network' volume management
> * Standard kernel output (Minimum, Full options ...)
> * Virtual machine support
> * /proc interface alternative to modutils/module-init-tools.
>                 That is, to have a directory of virtual nodes in /proc
>                 to provide the functionality of insmod, rmmod, lsmod &
>                 modprobe would be great -- especially from the viewpoint
>                 of recue disk images, etc.
> * Software RAID 0+1 perhaps?
>                 A lot of hardware RAID cards support it, why not the
>                 kernel?  By RAID 0+1 I mean mirror-RAIDing two (or more)
>                 stripe-RAID arrays.  (Or can this be done already?)
> * Transparent Software-RAID for IDE RAID cards...
>                 This could be done by using the Software RAID
>                 functionality of the kernel, but making the RAID
>                 interface transparent, so you only see a /dev/md?
>                 device, rather than multiple /dev/?da* entries.
> * hotplug RAM
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [2.7 "thoughts"] V0.3

[Jeff Sipek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What about 64-bit network statistics? (I'm working on an implementation that 
could be beneficial for many places in the kernel - right now it works, but 
needs some beautification.

Jeff.

- -- 
"I think there is a world market for maybe five computers."
		- Thomas Watson, chairman of IBM, 1943.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/hyvcwFP0+seVj/4RAq4eAJsGlDx2xpqlWiJ1Z8sS6mFHcgC8hQCfVyAI
Qwfz2rqBCeFH7+TE1ncKDg8=
=vh1J
-----END PGP SIGNATURE-----

Re: [2.7 "thoughts"] V0.3

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On Fri, 10 Oct 2003 15:17:30 MDT, Uncle Jens said:
> What about some type of kernel-based-DRM, where only properly(trusted) signed
> binaries can be executed?  For example, I could compile my public key in with
> the kernel and it would only run binaries that had been signed by my private
> key.  I feel that this would be a great security enhancement and would like t
o
> hear about any issues this may present.
> I've searched all over for a project that does something like this and have b
een
> unable to find one.  I'd like to start one up on my own, but lack the kernel
> development expertise.
> 
> I'm open for any input/flames/etc....

There are two basic problems with the idea:

1) It does nothing to prevent any of the usual abuses of a system - buffer
overflows, shellcode, and the like.  You get fed a bad packet, the signed
Apache binary overflows, and executes the signed /bin/sh that then calls
the signed /bin/echo to append stuff to the appropriate files to create
a back door.....

2) Unless you're working with a kiosk/embedded system where the number of
binaries is quite small, you're looking at a maintenance headache (remember,
if you blindly sign binaries without auditing every single one, you're really not
doing anything useful...)

A *much* better approach would be to do the following:

1) Mount everything either 'read only' or 'noexec', and use something like LSM
to make sure it doesn't get remounted.  So binaries off /home won't run, and
binaries on /usr can't be trojaned (barring OTHER breaches such as remounting,
or scribbling on the raw disk, etc...)

2) Fix the bypasses of noexec (like '/lib/ld-linux.so.2 /your/binary/here').

That's probably a much better way of addressing the "running unauthorized
binaries" threat, without taking a crypto signature hit on every exec().....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.7 "thoughts"] V0.3

[Michael Jensen]

I agree that it wouldn't have any effect on buffer overflows.  It would prevent
further abuse of the system unless the perpetrator was able to install and load
a modified kernel.  Even if they had root access, they would be unable to
execute backdoor binaries because they would not be signed with a trusted key. 
This would also thwart rootkits.

I also agree that there would be much maintenance and performance overhead.  But
there are some people/companies that are willing to sacrifice such things to
increase the security of their systems.

Another problem that I see is that it would be quite easy to get around signed
binaries if perl was one of those binaries.  Care would need to be taken in
deciding what is trusted and signed.

Does anyone have additional comments?

Michael

BTW - I like your suggestion of mounting everything either 'read only' or
'noexec', and using LSM.  I'm going to have to mess around with that.



Quoting Valdis.Kletnieks@vt.edu:

> On Fri, 10 Oct 2003 15:17:30 MDT, Uncle Jens said:
> > What about some type of kernel-based-DRM, where only properly(trusted)
> signed
> > binaries can be executed?  For example, I could compile my public key in
> with
> > the kernel and it would only run binaries that had been signed by my
> private
> > key.  I feel that this would be a great security enhancement and would like
> t
> o
> > hear about any issues this may present.
> > I've searched all over for a project that does something like this and have
> b
> een
> > unable to find one.  I'd like to start one up on my own, but lack the
> kernel
> > development expertise.
> > 
> > I'm open for any input/flames/etc....
> 
> There are two basic problems with the idea:
> 
> 1) It does nothing to prevent any of the usual abuses of a system - buffer
> overflows, shellcode, and the like.  You get fed a bad packet, the signed
> Apache binary overflows, and executes the signed /bin/sh that then calls
> the signed /bin/echo to append stuff to the appropriate files to create
> a back door.....
> 
> 2) Unless you're working with a kiosk/embedded system where the number of
> binaries is quite small, you're looking at a maintenance headache (remember,
> if you blindly sign binaries without auditing every single one, you're really
> not
> doing anything useful...)
> 
> A *much* better approach would be to do the following:
> 
> 1) Mount everything either 'read only' or 'noexec', and use something like
> LSM
> to make sure it doesn't get remounted.  So binaries off /home won't run, and
> binaries on /usr can't be trojaned (barring OTHER breaches such as
> remounting,
> or scribbling on the raw disk, etc...)
> 
> 2) Fix the bypasses of noexec (like '/lib/ld-linux.so.2 /your/binary/here').
> 
> That's probably a much better way of addressing the "running unauthorized
> binaries" threat, without taking a crypto signature hit on every exec().....
> 

Re: [2.7 "thoughts"] V0.3

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

On Fri, 10 Oct 2003 16:33:09 MDT, Michael Jensen said:

> I agree that it wouldn't have any effect on buffer overflows.  It would prevent
> further abuse of the system unless the perpetrator was able to install and load
> a modified kernel.  Even if they had root access, they would be unable to
> execute backdoor binaries because they would not be signed with a trusted key. 
> This would also thwart rootkits.

Umm... let me see if I got this straight...  They already exploited the system once
to get in originally, and you think that the same method that didn't stop them
from executing code to get in will also stop them from exploiting further?

All they need to do is park their code-to-execute in a file *anywhere* on the box,
and then invoke any of the numerous programs that have local buffer overflows,
and then use that program and an overflow sled to act as a poor-man's replacement
for /lib/ld-linux.

Hmm.. /bin/ls segfaults under some overflow conditions?  Just set up the
conditions, run /bin/ls, get the signed binary to run, and use it to load your
code. Game over. /bin/ls isn't exploitable?  Wander over to packetstorm and
pick and choose a ready-made exploit for lots of other stuff..

The basic problem here is that you're assuming that "the code loaded by exec()"
is trusted, therefor the code actually executed is trusted.  Given that most modern
processors are Von Neumann architectures rather than Harvard machines, that's a
problematic assumption.  That's why things like exec-shield or SELinux are probably
more productive directions - they are taking a different model:

exec-shield - We don't care if you're a trusted program, you're not executing off the stack.

SELinux - We don't care what binary you are, if you started in this security domain,
you're staying in it and having the restrictions enforced (yes, I know I'm simplifying
the issues with 'newrole' and the like)...

The important part is that what they *check* is actually related to the threat -
whereas checking the binary as protection against malicious code is essentially
a perverse case of a TOCTOU bug....

> Another problem that I see is that it would be quite easy to get around signed
> binaries if perl was one of those binaries.  Care would need to be taken in
> deciding what is trusted and signed.

As pointed out above, perl is just one of the problems.

> BTW - I like your suggestion of mounting everything either 'read only' or
> 'noexec', and using LSM.  I'm going to have to mess around with that.

Not to be snide or anything, if you haven't *already* investigated the existing
facilities (and found the issues with 'noexec', etc), you almost certainly haven't
thought through either the threat model or suitable defenses very thoroughly.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.7 "thoughts"] V0.3

[Michael Jensen]

Thanks for setting me straight.  For some reason I thought that whenever a
binary was executed (even through a buffer overflow), an exec() was issued.

Don't ask what I've been smoking...





Quoting Valdis.Kletnieks@vt.edu:

> On Fri, 10 Oct 2003 16:33:09 MDT, Michael Jensen said:
> 
> > I agree that it wouldn't have any effect on buffer overflows.  It would
> prevent
> > further abuse of the system unless the perpetrator was able to install and
> load
> > a modified kernel.  Even if they had root access, they would be unable to
> > execute backdoor binaries because they would not be signed with a trusted
> key. 
> > This would also thwart rootkits.
> 
> Umm... let me see if I got this straight...  They already exploited the
> system once
> to get in originally, and you think that the same method that didn't stop
> them
> from executing code to get in will also stop them from exploiting further?
> 
> All they need to do is park their code-to-execute in a file *anywhere* on the
> box,
> and then invoke any of the numerous programs that have local buffer
> overflows,
> and then use that program and an overflow sled to act as a poor-man's
> replacement
> for /lib/ld-linux.
> 
> Hmm.. /bin/ls segfaults under some overflow conditions?  Just set up the
> conditions, run /bin/ls, get the signed binary to run, and use it to load
> your
> code. Game over. /bin/ls isn't exploitable?  Wander over to packetstorm and
> pick and choose a ready-made exploit for lots of other stuff..
> 
> The basic problem here is that you're assuming that "the code loaded by
> exec()"
> is trusted, therefor the code actually executed is trusted.  Given that most
> modern
> processors are Von Neumann architectures rather than Harvard machines, that's
> a
> problematic assumption.  That's why things like exec-shield or SELinux are
> probably
> more productive directions - they are taking a different model:
> 
> exec-shield - We don't care if you're a trusted program, you're not executing
> off the stack.
> 
> SELinux - We don't care what binary you are, if you started in this security
> domain,
> you're staying in it and having the restrictions enforced (yes, I know I'm
> simplifying
> the issues with 'newrole' and the like)...

Re: [2.7 "thoughts"] V0.3

[Greg KH]

On Fri, Oct 10, 2003 at 03:17:30PM -0600, Uncle Jens wrote:
> What about some type of kernel-based-DRM, where only properly(trusted) signed
> binaries can be executed?

Already done for 2.6:
	http://sourceforge.net/projects/disec/

Grab the digsig package.

thanks,

greg k-h

Re: [2.7 "thoughts"] V0.3

[---]

El Fri, 10 Oct 2003 09:54:12 +0200 "Frederick, Fabian" <Fabian.Frederick@prov-liege.be> escribió:

> 2.7 "thoughts"
> Thanks to Gabor, Stuart, Stephan and others
> Don't hesitate to send me more or comment.

On thing me (as a user) would like to see is more user limits.
In particular; a (small) per-user mlock limit would be nice so a normal user
can mlock some memory to avoid buffer underruns without needing to give suid
permissions to cdrecord (which is what people uses now and guarantees you'll
have to update your cdrecord copy some day due to unavoidable security issues).

I wonder if this is a good wishlist item or just a stupid idea...



Diego Calleja

Re: [2.7 "thoughts"] V0.3

[William Lee Irwin III]

On Sat, Oct 11, 2003 at 04:04:35AM +0200, --- wrote:
> On thing me (as a user) would like to see is more user limits.
> In particular; a (small) per-user mlock limit would be nice so a normal user
> can mlock some memory to avoid buffer underruns without needing to give suid
> permissions to cdrecord (which is what people uses now and guarantees you'll
> have to update your cdrecord copy some day due to unavoidable security issues).
> I wonder if this is a good wishlist item or just a stupid idea...

cdrecord doesn't make sense because it requires privilege for device
access anyway.


-- wli

Re: [2.7 "thoughts"] V0.3

[---]

El Fri, 10 Oct 2003 19:13:07 -0700 William Lee Irwin III <wli@holomorphy.com> escribió:

> cdrecord doesn't make sense because it requires privilege for device
> access anyway.

Yes; thats can be fixed easily adding the ser to some group like this:
brw-rw----    1 root     cdrom     22,   0 2003-05-23 16:41 /dev/cd-rw
but no, cdrecord isn't a good example ;( and I can't think of other users
right now; so I guess the effort isn't worth of it...

Diego Calleja

Re: [2.7 "thoughts"] V0.3

[Gabor MICSKO]

2003-10-10, p keltezéssel Frederick, Fabian ezt írta:
> 2.7 "thoughts"
> Thanks to Gabor, Stuart, Stephan and others
> Don't hesitate to send me more or comment.

How about The Vinum Volume Manager?

>From Vinum homepage:

"The Vinum Volume Manager is a block device driver which implements
virtual disk drives. It isolates disk hardware from the block device
interface and maps data in ways which result in an increase in
flexibility, performance and reliability compared to the traditional
slice view of disk storage. Vinum implements the RAID-0, RAID-1 and
RAID-5 models, both individually and in combination.

Call for participation
Vinum is part of the base distribution of the FreeBSD operating system.
Versions exist for NetBSD and OpenBSD. I'm actively seeking people who
can help me port it to Linux."

More info: http://www.vinumvm.org/


Best regards, 

-- 
Windows not found
(C)heers, (P)arty or (D)ance?
-----------------------------------
Micskó Gábor
Compaq Accredited Platform Specialist, System Engineer (APS, ASE)
Szintézis Computer Rendszerház Rt.      
H-9021 Győr, Tihanyi Árpád út 2.
Tel: +36-96-502-216
Fax: +36-96-318-658
E-mail: gmicsko@szintezis.hu
Web: http://www.hup.hu/

Re: [2.7 "thoughts"] V0.3

[Zwane Mwaikambo]

On Sat, 11 Oct 2003, Gabor MICSKO wrote:

> 2003-10-10, p keltezéssel Frederick, Fabian ezt írta:
> > 2.7 "thoughts"
> > Thanks to Gabor, Stuart, Stephan and others
> > Don't hesitate to send me more or comment.
> 
> How about The Vinum Volume Manager?

We already have md and lvm, this doesn't appear to offer anything new.

Re: [2.7 "thoughts"] V0.3

[Meelis Roos]

GM> How about The Vinum Volume Manager?

To the best of my understanding, Vinum is roughly equivalent of MD / LVM
verion 1. Since then, FreeBSD has moved to GEOM and Linux has moved to
LVM2 (device mapper). And device mapper and GEOM are again roughly
equivalent.

-- 
Meelis Roos (mroos@linux.ee)