| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 12:15 UTC (Fri) by njwhite (subscriber, #51848)In reply to: The case for the /usr merge by angdraug Parent article: The case for the /usr merge
The security benefit of mounting read-only is marginal. If a user has access to write files which are marked read-only in the filesystem, they have access to remount /usr read-write. Unless I'm missing something?
(Log in to post comments)
The case for the /usr merge Posted Jan 27, 2012 16:52 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Read-write access can be controlled at the server for networked filesystems and not overridden by the client. Even in a local filesystem case it can prevent accidental modification or break canned exploit scripts
The case for the /usr merge Posted Jan 27, 2012 18:31 UTC (Fri) by iabervon (subscriber, #722) [Link]
Just having /usr mounted read-only isn't that big a win, but if the system will work with /usr mounted read-only, it will also work (which real benefits) if /usr is storage the system is technically incapable of modifying. (That is, where changing it requires doing something entirely different, like swapping CDs or flipping a physical switch on the device or something like that; or where it is a different system which can modify it.)
|
|||||||||||||