FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-14-2008, 01:41 AM
"Digby Tarvin"
 
Default Read-only root (/) except /et

On Sun, Apr 13, 2008 at 07:30:55PM -0400, Douglas A. Tutty wrote:
<snip>
> >
> > The trouble is that isn't really true. As long as you have standard
> > utilities like 'passwd' and 'chsh' normal users can cause the root
> > filesystem to be modified any time they want..
>
> No. The user isn't modifying anything really, its the suid utility
> which is. User's don't have write permission on the /etc/passwd file.
> The only security concern is if the suid utility is replaced by another;
> in other words, again root is compromised.

Well sure, when a user modifies somethign it always boils down to a progrma
doing it on the users behalf. The important point is that the user can
invoke such a change at any time. The suid file only restricts the nature
of the chance.

That means that in a standard config the root filesystem cannot be made
read-only without braeaking things, preventing one possible security
enhancing stategy.

> > And in the examples I gave (running root off a DVD or drive with
> > hardware write protect), a remount rw will only succeed in getting
> > write failures logged....
>
> So root turns off logging to. If we're talking about running off a DVD
> then this is a LiveCD scenario with union mounting.

so the worst case is a remount gains an infiltrator nothing if the filesystem
non-writeability is enforced via hardware.

And yes, I think a LiveCD is a very good example of the sort of hoops
you have to jump through to have some of the root filesystem content
run off read-only media.

> > But it isn't just security. It is another file system needing regular
> > backup, and fewer writes means less likelihood of corruption eg if power
> > goes off at the wrong instant..
>
> Well sure, that makes sense. However, the only part that needs the
> backup is /etc/ anyway, which would need backup if it was separate, so
> no gain there.

The /etc on a separate filesystem was the suggestion of the original
poster. Its not a solution that achieves my ideal of having only one
system and one user filesystem that have to be read/write.

> As for e.g. corruption, I'd suggest having a duplicate root filesystem
> taken care of by a script (which checks somehow that all is well) which
> rsyncs them. This second root fs would be on its own partition with its
> own entry in the boot loader. This suggests that /boot is on its own
> partition and it is very easy to have /boot ro.

Exactly what I am doing now on my bsd system:
skaro:/usr/home/digbyt> mount
/dev/wd0a on / (NFS exported, local)
/dev/wd0h on /usr (NFS exported, local, read-only)
/dev/wd0g on /var (local)
/dev/wd0f on /usr/local (NFS exported, local, nodev, read-only)
/dev/wd0e on /usr/home (NFS exported, local)
/dev/wd0d on /user1 (local, nodev, nosuid, read-only)
/dev/wd1h on /backup/usr (local, nodev, nosuid, read-only)
/dev/wd1f on /backup/local (local, nodev, nosuid, read-only)
/dev/wd1d on /backup/user1 (local, nodev, nosuid, read-only)
localhost:/cfs/null on /cfs/crypt
/dev/wd1a on /backup/root (local, nodev, nosuid, read-only)
/dev/wd1g on /backup/var (local, nodev, nosuid, read-only)
/dev/wd1e on /backup/home (local, nodev, nosuid, read-only)

Note that all my live partitions are rsync'd with identical
partitions on the backup disk every night, and by default all
except home, var and root are read-only. The backup scripts
know that they only have to backup live partitions that are
read-write, and to remount the backup filesystems read-write
during the procedure. If I do need to chance something on, for
example, /usr/local, I remount it and leave it read/write. The
backup scripts will see that it is r/w, back it up, and then make
it read-only again when they finish so that it won't be backed
up again till I repeat the process. User1 lets me arhive static
user files in a way that leaves them accessible without making
work for the backup scripts.

If it were not for root, then there would
be no writeable filesystem with suid and dev enabled.
And of course if root could be mounted read-only, that would be one less
filesystem that needed to be scanned for differences every night.

There is also a big saving in boot time if there is a crash, because
only filesystems mounted r/w will be dirty and need preening.

> > The files that are a problem are the ones where either a change can
> > result from user activity (passwrd/shadow) or where they are changed
> > by demons, such as resolv.conf. I don't mind explicit changes by the
> > administrator, who can take care or write-protects or reburning media.
>
> I'd suggest to approach it as a live CD thingy, its a well tried path.
> Anything else is frought with dragons.

Sure. I didn't mean to hijack the topic. Its just something I have
thought about and experimented with, so wanted to add my 2p worth to
the original posters suggestion/query.

Regards,
DigbyT


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 01:59 AM
Rich Healey
 
Default Read-only root (/) except /et

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

Digby Tarvin wrote:
> On Sun, Apr 13, 2008 at 07:30:55PM -0400, Douglas A. Tutty wrote:
> <snip>
>>> The trouble is that isn't really true. As long as you have standard
>>> utilities like 'passwd' and 'chsh' normal users can cause the root
>>> filesystem to be modified any time they want..
>> No. The user isn't modifying anything really, its the suid utility
>> which is. User's don't have write permission on the /etc/passwd file.
>> The only security concern is if the suid utility is replaced by another;
>> in other words, again root is compromised.
>
> Well sure, when a user modifies somethign it always boils down to a progrma
> doing it on the users behalf. The important point is that the user can
> invoke such a change at any time. The suid file only restricts the nature
> of the chance.
>
> That means that in a standard config the root filesystem cannot be made
> read-only without braeaking things, preventing one possible security
> enhancing stategy.
>
>>> And in the examples I gave (running root off a DVD or drive with
>>> hardware write protect), a remount rw will only succeed in getting
>>> write failures logged....
>> So root turns off logging to. If we're talking about running off a DVD
>> then this is a LiveCD scenario with union mounting.
>
> so the worst case is a remount gains an infiltrator nothing if the filesystem
> non-writeability is enforced via hardware.
>
> And yes, I think a LiveCD is a very good example of the sort of hoops
> you have to jump through to have some of the root filesystem content
> run off read-only media.
>
>>> But it isn't just security. It is another file system needing regular
>>> backup, and fewer writes means less likelihood of corruption eg if power
>>> goes off at the wrong instant..
>> Well sure, that makes sense. However, the only part that needs the
>> backup is /etc/ anyway, which would need backup if it was separate, so
>> no gain there.
>
> The /etc on a separate filesystem was the suggestion of the original
> poster. Its not a solution that achieves my ideal of having only one
> system and one user filesystem that have to be read/write.
>
>> As for e.g. corruption, I'd suggest having a duplicate root filesystem
>> taken care of by a script (which checks somehow that all is well) which
>> rsyncs them. This second root fs would be on its own partition with its
>> own entry in the boot loader. This suggests that /boot is on its own
>> partition and it is very easy to have /boot ro.
>
> Exactly what I am doing now on my bsd system:
> skaro:/usr/home/digbyt> mount
> /dev/wd0a on / (NFS exported, local)
> /dev/wd0h on /usr (NFS exported, local, read-only)
> /dev/wd0g on /var (local)
> /dev/wd0f on /usr/local (NFS exported, local, nodev, read-only)
> /dev/wd0e on /usr/home (NFS exported, local)
> /dev/wd0d on /user1 (local, nodev, nosuid, read-only)
> /dev/wd1h on /backup/usr (local, nodev, nosuid, read-only)
> /dev/wd1f on /backup/local (local, nodev, nosuid, read-only)
> /dev/wd1d on /backup/user1 (local, nodev, nosuid, read-only)
> localhost:/cfs/null on /cfs/crypt
> /dev/wd1a on /backup/root (local, nodev, nosuid, read-only)
> /dev/wd1g on /backup/var (local, nodev, nosuid, read-only)
> /dev/wd1e on /backup/home (local, nodev, nosuid, read-only)
>
> Note that all my live partitions are rsync'd with identical
> partitions on the backup disk every night, and by default all
> except home, var and root are read-only. The backup scripts
> know that they only have to backup live partitions that are
> read-write, and to remount the backup filesystems read-write
> during the procedure. If I do need to chance something on, for
> example, /usr/local, I remount it and leave it read/write. The
> backup scripts will see that it is r/w, back it up, and then make
> it read-only again when they finish so that it won't be backed
> up again till I repeat the process. User1 lets me arhive static
> user files in a way that leaves them accessible without making
> work for the backup scripts.
>
> If it were not for root, then there would
> be no writeable filesystem with suid and dev enabled.
> And of course if root could be mounted read-only, that would be one less
> filesystem that needed to be scanned for differences every night.
>
> There is also a big saving in boot time if there is a crash, because
> only filesystems mounted r/w will be dirty and need preening.
>
>>> The files that are a problem are the ones where either a change can
>>> result from user activity (passwrd/shadow) or where they are changed
>>> by demons, such as resolv.conf. I don't mind explicit changes by the
>>> administrator, who can take care or write-protects or reburning media.
>> I'd suggest to approach it as a live CD thingy, its a well tried path.
>> Anything else is frought with dragons.
>
> Sure. I didn't mean to hijack the topic. Its just something I have
> thought about and experimented with, so wanted to add my 2p worth to
> the original posters suggestion/query.
>
> Regards,
> DigbyT
>
>
It seems you want to install *BSD and just flag most of your
configuration nochg.

Regards


Rich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIArpzLeTfO4yBSAcRAnUFAJ9f48h4ovhOBAyne2cIYZ Yp2aRFmgCfTk8V
2+Y7mA7toL9fP6kfBxDIi3k=
=2LZE
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 04:25 AM
Andrew Malcolmson
 
Default Read-only root (/) except /et

Responding to the OP's original question (sorry, no longer have the
message), Voyage Linux is a Debian derivation for use on flash
storage which by default sets the root filesystem to read-only. A few
exceptions such as /var are mounted under tempfs and so run in memory.
The idea is to minimize writes to the flash storage.

The filesystem can be toggled back to read-write when needed.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-14-2008, 07:43 AM
NN_il_Confusionario
 
Default Read-only root (/) except /et

On Mon, Apr 14, 2008 at 11:59:16AM +1000, Rich Healey wrote:
> It seems you want to install *BSD and just flag most of your
> configuration nochg.

in linux, e2fsprogs have chattr and lsattr (I have not checked for other
filesystems, but I expect that some of the other filesystems, but not
all, have corresponding flags).

These flags become more useful in combination with Linux capabilitues
and *BSD securelevels.

In linux >= 2.2.x , cababilities (see the package lcap) can be used
where BSD securelevels are used (and are much more fine grained that the
traditional securelevels of *BSD, but they are not so fine-grained as
one might reasonably want. Modern Linux and modern *BSD have also other,
more adavanced, security measures).

Linux capabilities are also used by linux vservers, which rougly
correspond to *BSD jails and Solaris zones. (Linux has also other
similar things, but the vservers are the only one for which debian
provides pre-compiled kernels)

Linux kernels try to accept contibutions from much more people, try to
support much more things than *BSD kernels (but also less things in some
specialized areas), and correspondingly much more (security and
non-security) bugs are found.

And so on.

Net search engines find many comparations between Linux and *BSD kernels
and between GNU and *BSD userland. Most of them are old, incomplete, not
so competent and so on. This might be an occasion to add another
flamefest to the list. Or to work to the ongoing port of debian glibc
based userland to the FreeBSD kernel.

--
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 03:08 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org