Hi,

while thinking about limiting mount permissions of kernel-filesystems I
stumbled across your project as one of very few resources where has ever
been thought about this issue, so thanks for that for the first :)

While further thinking about limiting mount permissions for sysfs I found
the following in your mailinglist archive...

On Fri, Dec 03, 2004 at 07:07:10PM -0700, Archaic wrote:
> On Fri, Dec 03, 2004 at 08:37:33PM -0500, Robert Connolly wrote:
> > the following a better reccomendation?
> > proc           /proc        proc     rw,nodev,nosuid 0     0
> > sysfs          /sys         sysfs    rw,nodev,nosuid 0     0
> > devpts         /dev/pts     devpts   rw,nodev,nosuid,gid=4,mode=620  0     0
> > shm            /dev/shm     tmpfs    rw,nodev,nosuid 0     0
> > Can noexec be added to all of these too? /var shouldn't need exec either.
> I would think nodev should be taken out of devpts and sysfs since they
> are dev directories.

Are there any new insights for that? Of course, devpts contains devices
only, so nodev there is out of discussion.
However, as far as I can see, sysfs contains not a single device node at
all. After crawling a bit through the kernel source I'm not even sure if
it is possible at all to *create* a device node there.
So I personally think, nodev would be okay for sysfs. Does anybody
perhaps have opposite experiences?

And when we are at it once...

> I've had success with noexec on proc, var, and devpts. I've not tried on
> shm and sysfs.

noexec on devpts is IMHO okay, since it *only* contains device nodes.
Currently, you don't have that in chapter07/fstab. Is there any reason
why?


PS: Please CC: me on replies, since I'm not on the list (M-F'up2 should
be set accordingly).


Thanks for your work & regards
   Mario
-- 
Whenever you design a better fool-proof software,
the genetic pool will always design a better fool.

Attachment: signature.asc
Description: Digital signature

-- 
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to