[2.7 "thoughts"] V0.3
Frederick, Fabian
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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jens Axboe
> 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
John Bradford
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.
William Lee Irwin III
> 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
Rik van Riel
> > * 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
Uncle Jens
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
Jeff Sipek
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-----
Valdis.K...@vt.edu
> 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().....
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.K...@vt.edu:
Valdis.K...@vt.edu
> 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.
Michael Jensen
binary was executed (even through a buffer overflow), an exec() was issued.
Don't ask what I've been smoking...
Quoting Valdis.K...@vt.edu:
---
> 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
William Lee Irwin III
> 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
Greg KH
> 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
---
> 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
Gabor MICSKO
> 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: gmi...@szintezis.hu
Web: http://www.hup.hu/
Zwane Mwaikambo
> 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.
Meelis Roos
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 (mr...@linux.ee)