public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Uncle Jens <kernel@millcreeksys.com>
To: "Frederick, Fabian" <Fabian.Frederick@prov-liege.be>
Cc: "Linux-Kernel (E-mail)" <linux-kernel@vger.kernel.org>
Subject: Re: [2.7 "thoughts"] V0.3
Date: Fri, 10 Oct 2003 15:17:30 -0600	[thread overview]
Message-ID: <1065820650.3f8721ea4162b@secure.millcreeksys.com> (raw)
In-Reply-To: <D9B4591FDBACD411B01E00508BB33C1B01F24E98@mesadm.epl.prov-liege.be>

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/
> 



  parent reply	other threads:[~2003-10-10 21:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-10  7:54 [2.7 "thoughts"] V0.3 Frederick, Fabian
2003-10-10  8:01 ` Jens Axboe
2003-10-10  8:13 ` John Bradford
2003-10-10 14:38   ` Rik van Riel
2003-10-10  9:11 ` William Lee Irwin III
2003-10-10 21:17 ` Uncle Jens [this message]
2003-10-10 21:59   ` Jeff Sipek
2003-10-10 22:05   ` Valdis.Kletnieks
2003-10-10 22:33     ` Michael Jensen
2003-10-10 23:13       ` Valdis.Kletnieks
2003-10-11  1:54         ` Michael Jensen
2003-10-11  2:23   ` Greg KH
2003-10-11  2:04 ` ---
2003-10-11  2:13   ` William Lee Irwin III
2003-10-11  2:30     ` ---
2003-10-11  6:24 ` Gabor MICSKO
2003-10-11  6:43   ` Zwane Mwaikambo
2003-10-11 10:56   ` Meelis Roos

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=1065820650.3f8721ea4162b@secure.millcreeksys.com \
    --to=kernel@millcreeksys.com \
    --cc=Fabian.Frederick@prov-liege.be \
    --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