Why not simply unset the write bit for all three groups of users?
That seems to be enough to prevent file modification.
Immutable seems to only add one more protection level in case of
misconfiguration on standard access right bits. Is that right?
On Sun, Apr 17, 2005 at 11:54:34AM -0400, Xin Zhao wrote:
> Why not simply unset the write bit for all three groups of users?
> That seems to be enough to prevent file modification.
>
> Immutable seems to only add one more protection level in case of
> misconfiguration on standard access right bits. Is that right?
With immutable, even root cannot modify the file accidentely. It is
very useful for critical configuration files.
Willy
Thanks for your reply.
Yes. I know, with immutable, even root cannot modify sensitive
files. What I am curious is if an intruder has root access, he may
have many ways to turn off the immutable protection and modify files.
So immutable is designed just to prevent a valid root from making
silly mistakes?
Xin
On 4/17/05, Willy Tarreau <[email protected]> wrote:
> On Sun, Apr 17, 2005 at 11:54:34AM -0400, Xin Zhao wrote:
> > Why not simply unset the write bit for all three groups of users?
> > That seems to be enough to prevent file modification.
> >
> > Immutable seems to only add one more protection level in case of
> > misconfiguration on standard access right bits. Is that right?
>
> With immutable, even root cannot modify the file accidentely. It is
> very useful for critical configuration files.
>
> Willy
>
>
On Apr 17, 2005, at 12:12, Xin Zhao wrote:
> Thanks for your reply.
>
> Yes. I know, with immutable, even root cannot modify sensitive
> files. What I am curious is if an intruder has root access, he may
> have many ways to turn off the immutable protection and modify files.
> So immutable is designed just to prevent a valid root from making
> silly mistakes?
>
> Xin
But without the proper capability, root _can't_ change the immutable
bit. Of course, that also applies to DAC checks too. Personally, I
find the immutable bit most useful at preventing accidents. I have
several scripts designed specifically to access the same file, and I
want to prevent one of my admins from accidentally editing that file
by hand. The best way is with a big comment in the file itself and
the immutable bit.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
On Sun, Apr 17, 2005 at 12:12:13PM -0400, Xin Zhao wrote:
> Thanks for your reply.
>
> Yes. I know, with immutable, even root cannot modify sensitive
> files. What I am curious is if an intruder has root access, he may
> have many ways to turn off the immutable protection and modify files.
> So immutable is designed just to prevent a valid root from making
> silly mistakes?
Probably yes, but it also provides a first level of security :
- if the intruder launches programs blindly, he will not systematically
get write access. Eg: if he abuses a CGI to call things like
echo r00t::0:0::/:/bin/sh >>/etc/passwd
it will not work.
- if you give root access to other people on your file-system but you
don't give them the CAP_LINUX_IMMUTABLE capability, they will not be
able to modify the protected files. Useful when those files are the
ones you use to grant them access ;-)
Regards,
Willy
In article <[email protected]> you wrote:
> Why not simply unset the write bit for all three groups of users?
> That seems to be enough to prevent file modification.
# touch test
# chmod a-w test
# echo test > test
# cat test
test
Because this does not protect against writes from root and it does not
protect against root setting the flags again.
Greetings
Bernd
In article <[email protected]> you wrote:
> Yes. I know, with immutable, even root cannot modify sensitive
> files. What I am curious is if an intruder has root access, he may
> have many ways to turn off the immutable protection and modify files.
If you secure your system correctly (i.e make /dev/*mem imutable, disalow
module loading, restrict io... (and I admit it is quite complicated to find
all holes and secure it correctly without additional ptches like SELinux))
then even root cant gt arround immutable or append only (without rebooting).
Greetings
Bernd
We can certainly harden the system, but sometime the vulnerability in
kernel is hard to detect and protect. For example, the brk()
vulnerablitiy found in Linux kernel. All the security mechanisms you
mentioned have to rely on a healthy kernel. Unfortunately, the kernel
itself could be compromised too. Although it could be very difficult,
thereotically speaking, any kernel level protection, including
SELinux, could be disabled after the kernel is compromised. Am I
missing some points here?
On 4/17/05, Bernd Eckenfels <[email protected]> wrote:
> In article <[email protected]> you wrote:
> > Yes. I know, with immutable, even root cannot modify sensitive
> > files. What I am curious is if an intruder has root access, he may
> > have many ways to turn off the immutable protection and modify files.
>
> If you secure your system correctly (i.e make /dev/*mem imutable, disalow
> module loading, restrict io... (and I admit it is quite complicated to find
> all holes and secure it correctly without additional ptches like SELinux))
> then even root cant gt arround immutable or append only (without rebooting).
>
> Greetings
> Bernd
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sun, Apr 17, 2005 at 07:48:50PM -0400, Xin Zhao wrote:
> any kernel level protection, including
> SELinux, could be disabled after the kernel is compromised. Am I
> missing some points here?
No, Immutable bit is an application of capabilities (or securelevel), you
are right.
If the kernel is compromised, the kernel is compromised. However immutable
bit can make it hard to circumvent kernel's protetion, even for root
attackers
Gruss
Bernd
On Sun, 17 Apr 2005, Xin Zhao wrote:
> Why not simply unset the write bit for all three groups of users?
> That seems to be enough to prevent file modification.
another usage: if you "chattr +i /var" while /var is unmounted, then root
is unlikely to accidentally create files/dirs in /var -- and when you
mount the real /var on top it works fine. i tend to protect all my mount
points this way (especially those in /mnt) to avoid my own dumb mistakes.
-dean
Hi Dean :)
* dean gaudet <[email protected]> dixit:
> > Why not simply unset the write bit for all three groups of users?
> > That seems to be enough to prevent file modification.
> another usage: if you "chattr +i /var" while /var is unmounted, then root
> is unlikely to accidentally create files/dirs in /var -- and when you
> mount the real /var on top it works fine. i tend to protect all my mount
> points this way (especially those in /mnt) to avoid my own dumb mistakes.
Hey, man, that's GREAT :)) I'm going to do the same on my system,
thanks for the suggestion.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...
On Apr 23, 2005, at 12:50, dean gaudet wrote:
> On Sun, 17 Apr 2005, Xin Zhao wrote:
>
>> Why not simply unset the write bit for all three groups of users?
>> That seems to be enough to prevent file modification.
>
> another usage: if you "chattr +i /var" while /var is unmounted, then
> root
> is unlikely to accidentally create files/dirs in /var -- and when you
> mount the real /var on top it works fine. i tend to protect all my
> mount
> points this way (especially those in /mnt) to avoid my own dumb
> mistakes.
If you chmod 000 /var beforehand (While it's still unmounted, of
course),
then it's also blindingly obvious that it's not mounted in an ls -l :-D.
I too have used this trick on many/most of my systems.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
Hi Kyle :)
* Kyle Moffett <[email protected]> dixit:
> >another usage: if you "chattr +i /var" while /var is unmounted,
> >then root is unlikely to accidentally create files/dirs in /var --
> >and when you mount the real /var on top it works fine. i tend to
> >protect all my mount points this way (especially those in /mnt) to
> >avoid my own dumb mistakes.
> If you chmod 000 /var beforehand (While it's still unmounted, of
> course), then it's also blindingly obvious that it's not mounted in
> an ls -l :-D. I too have used this trick on many/most of my
> systems.
I was doing exactly that, but it has its drawbacks: root still
can create files by accident. I've been hit by this a couple of
times :( For example, as root, I issue the mount command with a typo,
and before I can read the result of the command I've already typed a
'cp' or 'mv' command, 'sync' and 'umount'. Yes, I know, I should read
carefully what I type as root and the result of the commands, and I
do except when issuing harmless commands as 'cp' O:))) My fault, yes,
but it can be solved easily with the trick provided by Dean ;)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...
On Apr 23, 2005, at 15:12, DervishD wrote:
> * Kyle Moffett <[email protected]> dixit:
>>> another usage: if you "chattr +i /var" while /var is unmounted,
>>> then root is unlikely to accidentally create files/dirs in /var --
>>> and when you mount the real /var on top it works fine. i tend to
>>> protect all my mount points this way (especially those in /mnt) to
>>> avoid my own dumb mistakes.
>> If you chmod 000 /var beforehand (While it's still unmounted, of
>> course), then it's also blindingly obvious that it's not mounted in
>> an ls -l :-D. I too have used this trick on many/most of my
>> systems.
> I was doing exactly that, but it has its drawbacks: root still
> can create files by accident. [...]
Ah, I meant in combination with the above trick:
# umount /var
# chmod 000 /var
# chattr +i /var
# ls -alhd /var
d--------- 2 root root 68 Apr 23 16:36 /var
# mount /var
If I forget to mount var, not only can I not create files, I'll also
notice when I "ls -alh /".
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
Hi Kyle :)
* Kyle Moffett <[email protected]> dixit:
> On Apr 23, 2005, at 15:12, DervishD wrote:
> > * Kyle Moffett <[email protected]> dixit:
> >>>another usage: if you "chattr +i /var" while /var is unmounted,
> >>>then root is unlikely to accidentally create files/dirs in /var --
> >>>and when you mount the real /var on top it works fine. i tend to
> >>>protect all my mount points this way (especially those in /mnt) to
> >>>avoid my own dumb mistakes.
> >>If you chmod 000 /var beforehand (While it's still unmounted, of
> >>course), then it's also blindingly obvious that it's not mounted in
> >>an ls -l :-D. I too have used this trick on many/most of my
> >>systems.
> >I was doing exactly that, but it has its drawbacks: root still
> >can create files by accident. [...]
> Ah, I meant in combination with the above trick:
Oh, yes, I was meaning exactly that. I prefer to have '000'
permissions on directories that act as mountpoints just to see at a
glance whether they are mounted or not. You're right, the chattr +i
is just another protection, not a simple visual one ;)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/
It's my PC and I'll cry if I want to...