basically security of linux

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

basically security of linux

Andreas Matthus
Hallo,

I manage a lot of debian servers and try to install often the updates.
So I had in mind my systems are well prepaired. (I follow also other
security rules  ;-)  )

But since some days I mull over a question: What happens  if a user run
a selfcopy from a program with a security hole? I'm afraid he can get
root-rights. Isn't it?

with regards
Andreas Matthus


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Sébastien Le Ray-2
Le Fri, 16 Jan 2009 10:31:35 +0100,
Andreas Matthus <[hidden email]> a écrit :

> Hallo,
>
> I manage a lot of debian servers and try to install often the updates.
> So I had in mind my systems are well prepaired. (I follow also other
> security rules  ;-)  )
>
> But since some days I mull over a question: What happens  if a user
> run a selfcopy from a program with a security hole? I'm afraid he can
> get root-rights. Isn't it?
>
> with regards
> Andreas Matthus
>
Hi,

I'd say that except in the case of kernel bug, non-root users cannot
get root rights with a non root running program...

Regards

Sébastien

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Michael Loftis
In reply to this post by Andreas Matthus


--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus
<[hidden email]> wrote:

> Hallo,
>
> I manage a lot of debian servers and try to install often the updates.
> So I had in mind my systems are well prepaired. (I follow also other
> security rules  ;-)  )
>
> But since some days I mull over a question: What happens  if a user run
> a selfcopy from a program with a security hole? I'm afraid he can get
> root-rights. Isn't it?

In general, no.  This requires an exploitable kernel bug.  That said, there
have been some of these in the past, and new ones will likely be discovered
in the future, but that's far more rare.  Anything you run as root should
only ever come from trusted sources for this reason.

Windows is a different matter.  There's so many ways to break local
security on windows it's not funny.  But with Linux, and any Unix in
general, you can not arbitrarily escalate your privileges.  The way
applications like su, and sudo work is through the SetUID bit on their
executable.  What this does is causes the kernel to run the application as
the user that owns the file - root in the case of su and sudo - this lets
them elevate your privilege levels if you pass their access checks.  That's
why SetUID executables can be dangerous.  You have to trust them.  Very few
programs are SetUID 0/root.

Linux/UNIX was designed for running arbitrary programs by arbitrary users,
and keeping them all separate from eachother, secure from eachother's
malicious intent or accidents, provided you follow secure permissions on
files and directories.

root is the only user who has exceptions to this, root has the capability
to read or write any file (I know i know guys there's SELinux and stuff
like that for CAP management but we're talking the general case here).



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Boyd Stephen Smith Jr.-3
On Friday 2009 January 16 04:13:10 Michael Loftis wrote:
>--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus
><[hidden email]> wrote:
>> But since some days I mull over a question: What happens  if a user run
>> a selfcopy from a program with a security hole? I'm afraid he can get
>> root-rights. Isn't it?
>In general, no.  This requires an exploitable kernel bug.  That said, there
>have been some of these in the past, and new ones will likely be discovered
>in the future, but that's far more rare.  Anything you run as root should
>only ever come from trusted sources for this reason.

What about hardlinking the suid-root binaries to a hidden location, waiting
for a security hole to be found/fixed, and then running the old binary to
exploit the hole?  Does dpkg handle suid/sgid files so that this is
prevented?
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

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

Boyd Stephen Smith Jr. wrote:
> What about hardlinking the suid-root binaries to a hidden location, waiting
> for a security hole to be found/fixed, and then running the old binary to
> exploit the hole?  

IIRC, a hard link is the same file called two different names. If
dpkg/apt change the file in one location (security update), the other
one will be changed as well [1]...

You'd have to *copy* the hard linked file, but that would still not
allow you to copy it back later or to retain it's suid properties.

Am I missing something?

Johannes

[1] http://en.wikipedia.org/wiki/Hard_link
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklw0fkACgkQC1NzPRl9qEXaKACfX8VfBxpZsSH7Lf0HAGC9JL4b
298AoIAqW+BtPtRZ6wZvT37t4zujq3a0
=rOKy
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Boyd Stephen Smith Jr.-3
On Friday 2009 January 16 12:29:13 Johannes Wiedersich wrote:
>Boyd Stephen Smith Jr. wrote:
>> What about hardlinking the suid-root binaries to a hidden location,
>> waiting for a security hole to be found/fixed, and then running the old
>> binary to exploit the hole?
>
>IIRC, a hard link is the same file called two different names. If
>dpkg/apt change the file in one location (security update), the other
>one will be changed as well [1]...

True enough.  However, if you unlink the old version before writing the new
version, you have a problem.  IIRC, GNU cp and GNU mv does the unlink/link
rather than opening the destination with O_CREAT|O_TRUNC|O_WRITE.
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Michael Loftis
In reply to this post by Johannes Wiedersich


--On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich
<[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Boyd Stephen Smith Jr. wrote:
>> What about hardlinking the suid-root binaries to a hidden location,
>> waiting  for a security hole to be found/fixed, and then running the old
>> binary to  exploit the hole?

This is why compromised systems can't be trusted ever again.  Taht said,
there are utilities and methods for finding rogue SUID binaries.  Tripwire
comes to mind, there are many others too.

>
> IIRC, a hard link is the same file called two different names. If
> dpkg/apt change the file in one location (security update), the other
> one will be changed as well [1]...

That only holds true of edit-in-place.  Something that most packaging
systems do not do, the reason being is that with the way modern
systems/kernels execute code, this would modify running code (They
generally mmap the code, readonly, into the processes address space).

FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use error.
However, you can't create a hard link on a file you don't own, you can't do
it across drives, and I don't think your hardlinked copy retains SUID
bits....The last bit I could be wrong though.

> You'd have to *copy* the hard linked file, but that would still not
> allow you to copy it back later or to retain it's suid properties.
>
> Am I missing something?
>
> Johannes
>
> [1] http://en.wikipedia.org/wiki/Hard_link
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklw0fkACgkQC1NzPRl9qEXaKACfX8VfBxpZsSH7Lf0HAGC9JL4b
> 298AoIAqW+BtPtRZ6wZvT37t4zujq3a0
> =rOKy
> -----END PGP SIGNATURE-----
>
>
> --
> To UNSUBSCRIBE, email to [hidden email]
> with a subject of "unsubscribe". Trouble? Contact
> [hidden email]
>



--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

François Bottin
In reply to this post by Boyd Stephen Smith Jr.-3
Boyd Stephen Smith Jr. wrote:
> What about hardlinking the suid-root binaries to a hidden location, waiting
> for a security hole to be found/fixed, and then running the old binary to
> exploit the hole?  Does dpkg handle suid/sgid files so that this is
> prevented?

Hi,

Having /home, /tmp, (/usr)?/s?bin and /opt on different partitions is a
solution. A normal user should not have the right to create a file
outside /home or /tmp, and there should be no SUID file outside
(/usr)?/s?bin or /opt. No hard-linking is possible across devices.

        François.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basic security of linux

Vincent Zweije-6
In reply to this post by Michael Loftis
On Fri, Jan 16, 2009 at 01:45:44PM -0700, Michael Loftis wrote:

||  --On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich  
||  <[hidden email]> wrote:

||  > IIRC, a hard link is the same file called two different names. If
||  > dpkg/apt change the file in one location (security update), the other
||  > one will be changed as well [1]...

Hm! If it's not already that way, it might be a nice idea for a package
manager to reset setuid bits before removing a setuid executable.

||  That only holds true of edit-in-place.  Something that most packaging  
||  systems do not do, the reason being is that with the way modern  
||  systems/kernels execute code, this would modify running code (They  
||  generally mmap the code, readonly, into the processes address space).

I expect the mmapped executable to be private and copy on write, so you
can write all you want but you can't modify the map that's already in
use by the process. You'll only manage breaking the sharing. I know you
can delete the mmapped file.

||  FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use
||  error. However, you can't create a hard link on a file you don't own, you
||  can't do it across drives, and I don't think your hardlinked copy retains
||  SUID bits....The last bit I could be wrong though.

Yes, you're wrong there. Permissions are attached to the inode, not the
directory entry. (That would be something, hard link someone else's files,
change the permissions and hack it...)

||  > You'd have to *copy* the hard linked file, but that would still not
||  > allow you to copy it back later or to retain it's suid properties.

Your copy will be yours. If you decide to set the suid bit on your copy,
it would be setuid to *you* instead of to the other guy.

Ciao.                                                             Vincent.
--
Vincent Zweije <[hidden email]>    | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Boyd Stephen Smith Jr.-3
In reply to this post by Michael Loftis
On Friday 2009 January 16 14:45:44 Michael Loftis wrote:
>--On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich
><[hidden email]> wrote:
>> Boyd Stephen Smith Jr. wrote:
>>> What about hardlinking the suid-root binaries to a hidden location,
>>> waiting  for a security hole to be found/fixed, and then running the old
>>> binary to  exploit the hole?
>
>This is why compromised systems can't be trusted ever again.

No need to compromise the system in the default partition layout.  See below.

>Taht said,
>there are utilities and methods for finding rogue SUID binaries.  Tripwire
>comes to mind, there are many others too.

Yes, I know, but there could ways to mitigate the attack vector in the core
system so that (this feature of) tripwire isn't needed.

>> IIRC, a hard link is the same file called two different names. If
>> dpkg/apt change the file in one location (security update), the other
>> one will be changed as well [1]...
>
>That only holds true of edit-in-place.  Something that most packaging
>systems do not do, the reason being is that with the way modern
>systems/kernels execute code, this would modify running code (They
>generally mmap the code, readonly, into the processes address space).

Hrm, I didn't know you could patch running programs like this.  I assumed that
the kernels actively prevented this through COW or other methods.

>FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use error.

>However, you can't create a hard link on a file you don't own,

Not true.  You can create a hard link to any file as long as the new link is
in directory to which you can write.

>you can't do
>it across drives,

Right, but the default partitioning puts /sbin /usr/sbin etc. on the same
filesystem as /home and /tmp, exposing the system to these attacks.

>and I don't think your hardlinked copy retains SUID
>bits....The last bit I could be wrong though.

Yes, it does.  Permission bits are part of the file data (inodes), not part of
the directory data (dirents) so the permissions/owner/group is the same on
all (hard) links to a single file.

Transcript from my system:
$ sudo /bin/sh -c 'echo test > file'
root's password:
$ ln file my_file
$ ls -l *file
-rw-r--r-- 2 root root 5 2009-01-16 14:54 file
-rw-r--r-- 2 root root 5 2009-01-16 14:54 my_file
$ ls -ld .
drwxr-xr-x 99 bss users 5168 2009-01-16 14:54 .
$ sudo /bin/sh -c 'echo test > file'
$ ls -l *file
-rw-r--r-- 2 root root 0 2009-01-16 14:54 file
-rw-r--r-- 2 root root 0 2009-01-16 14:54 my_file
$ sudo chmod 7777 file
$ ls -l *file
-rwsrwsrwt 2 root root 0 2009-01-16 15:03 file
-rwsrwsrwt 2 root root 0 2009-01-16 15:03 my_file
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basic security of linux

Boyd Stephen Smith Jr.-3
In reply to this post by Vincent Zweije-6
On Friday 2009 January 16 15:06:33 Vincent Zweije wrote:
>On Fri, Jan 16, 2009 at 01:45:44PM -0700, Michael Loftis wrote:
>||  --On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich
>||  <[hidden email]> wrote:
>||  > IIRC, a hard link is the same file called two different names. If
>||  > dpkg/apt change the file in one location (security update), the other
>||  > one will be changed as well [1]...
>
>Hm! If it's not already that way, it might be a nice idea for a package
>manager to reset setuid bits before removing a setuid executable.

Removing the suid bits would be sufficient.  As dpkg is already running as
root, this could normally be done just before the normal
remove/upgrade/install process.

>||  Something that most packaging
>||  systems do not do, the reason being is that with the way modern
>||  systems/kernels execute code, this would modify running code (They
>||  generally mmap the code, readonly, into the processes address space).
>
>I expect the mmapped executable to be private and copy on write, so you
>can write all you want but you can't modify the map that's already in
>use by the process. You'll only manage breaking the sharing.
>
>||  FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use
>||  error.
As does Linux (openSUSE):
$ sudo /bin/sh -c '> /opt/kde3/bin/kget'
/bin/sh: /opt/kde3/bin/kget: Text file busy
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Repasi Tibor
In reply to this post by Boyd Stephen Smith Jr.-3
Boyd Stephen Smith Jr. wrote:
> Did you mean this to go to the list?  I've replied directly to you, but feel
> free to repost my mail or part thereof to the list if you believe the
> discussion could continue there.
>  
Sorry, my fault.

> On Friday 2009 January 16 13:03:53 you wrote:
>  
>> Boyd Stephen Smith Jr. wrote:
>>    
>>> What about hardlinking the suid-root binaries to a hidden location,
>>> waiting for a security hole to be found/fixed, and then running the old
>>> binary to exploit the hole?  Does dpkg handle suid/sgid files so that this
>>> is prevented?
>>>      
>> Against hard linking attacks, as You described, it is recommended to
>> have user-writable directories (usually /home and /tmp) on separate
>> filesystems (since hard linking only works within one filesystem). These
>> filesystems should be mounted with nosuid and nodev options. Nosuid
>> protects against exploiting of vulnerable suid/sgid binaries, while
>> nodev denies access to probably exploitable kernel code (i.e. device
>> drivers). The only remaining vulnerability is through an exploitable
>> syscall.
>>
>> Also it is recommended to make use of noexec on filesystems containing
>> data only  (e.g. /var/log, /var/mail) and ro for filesystems containing
>> application binaries (e.g. /usr). That makes it a bit inconvenient to
>> upgrade applications, since you have to remount /usr with rw before and
>> with ro after doing the upgrade.
>>    
>
> Is this documented somewhere?  I can understand Debian not doing this
> partitioning by default, but it should be easily accessible to those that
> want to "harden" their systems.  It would also be nice to see what
> no$feature/ro options Debian supports for various filesystems.
>
>  
Search for the Securing Debian Manual and see:
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2

This manual describes a lot of security improvements for Debian
installation. You probably does not need them all, however,  its a nice
guide to Unix/Linux security.

> At least once, I had a nodev /home bite me.  Of course, I really shouldn't be
> building chroots in home, but it was the filesystem with the most space at
> the time.
>
>  
>> The dpkg tool, and no other package manager, does not, can not, however,
>> it is not intended to prevent hard linking of suid/sgid binaries.
>>    
>
> It certainly could mitigate the risk by intentionally writing zeros to the
> inode(s) containing removed suid binaries.  This does not require raw-writing
> the disk or having non-working binaries for any period of time either.  IIRC,
> Gentoo provided such a feature at some point.  I could see dpkg handling it
> by hardlinking any suid binaries that are "to be replaced" or "to be removed"
> before doing a remove/upgrade/install normally and then writing zeros to the
> saved file before unlinking it.  If broken binaries can be accepted for some
> period of time, they can simply be overwritten with zeros before the normal
> remove/upgrade/install process.
>  
On inode filesystems a file is removed when the link counter gets zero
and the file is not open. When you open a file and unlink it, the file
will be kept till it is open.

To overwrite a file before it is upgraded is _very_ dangerous. What if
the upgrade won't work? Then you probably lost your libc, or something?
Therefore, the safe way for an upgrade is to create create the new file
with an temporary name, and when it is ready, copy it with a single move
operation over the original.

Imagine the following. A server (e.g. apache or sshd) is running and
using a certain library. The library is opened and is read from time to
time. If you overwrite this file with zeros, your server crashes. If you
let him use the obsolete library till its upgrade is finished, then
force it to restart, the service can have a downtime of less than a second.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Boyd Stephen Smith Jr.-3
On Friday 2009 January 16 15:49:46 Repasi Tibor wrote:

>Boyd Stephen Smith Jr. wrote:
>> On Friday 2009 January 16 13:03:53 you wrote:
>>> Boyd Stephen Smith Jr. wrote:
>>>> What about hardlinking the suid-root binaries to a hidden location,
>>>> waiting for a security hole to be found/fixed, and then running the old
>>>> binary to exploit the hole?  Does dpkg handle suid/sgid files so that
>>>> this is prevented?
>>> Against hard linking attacks, as You described, it is recommended to
>>> have user-writable directories (usually /home and /tmp) on separate
>>> filesystems (since hard linking only works within one filesystem).
>> Is this documented somewhere?
>Search for the Securing Debian Manual and see:
>http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2
Reading there and clicking through a bit I find this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225692
which indicates that dpkg does, in fact, take active steps to prevent the
hardlinking attacks I described.

That is good to know.

>> It certainly could mitigate the risk by intentionally writing zeros to the
>> inode(s) containing removed suid binaries.  This does not require
>> raw-writing the disk or having non-working binaries for any period of time
>> either.  I could see
>> dpkg handling it by hardlinking any suid binaries that are "to be
>> replaced" or "to be removed" before doing a remove/upgrade/install
>> normally and then writing zeros to the saved file before unlinking it.  If
>> broken binaries can be accepted for some period of time, they can simply
>> be overwritten with zeros before the normal remove/upgrade/install
>> process.
>
>On inode filesystems a file is removed when the link counter gets zero
>and the file is not open. When you open a file and unlink it, the file
>will be kept till it is open.
Okay, I know that, and I didn't suggest doing anything to a file that had 0
link count.

>To overwrite a file before it is upgraded is _very_ dangerous. What if
>the upgrade won't work? Then you probably lost your libc, or something?
>Therefore, the safe way for an upgrade is to create create the new file
>with an temporary name, and when it is ready, copy it with a single move
>operation over the original.

Which is why my primary option had no period of time when the file at
path /suid/binary/needed/by/upgrade_process had (a) bad content, (b) missing
executable bit, or (c) missing suid bit.

Turns out if I read just a little bit more, I wouldn't have wasted so much
bandwidth.  Sorry, guys.  Big thanks to all the DDs that fix my problems
before I think about them.
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Mike Dornberger
In reply to this post by Boyd Stephen Smith Jr.-3
Hi,

On Fri, Jan 16, 2009 at 03:13:10PM -0600, Boyd Stephen Smith Jr. wrote:
> On Friday 2009 January 16 14:45:44 Michael Loftis wrote:

[hardlinking (suid binaries in hope a vulnerability will be found)]
> >you can't do
> >it across drives,
>
> Right, but the default partitioning puts /sbin /usr/sbin etc. on the same
> filesystem as /home and /tmp, exposing the system to these attacks.

just an addition: Often I've seen /home as a separate mount (mounted
nosuid,nodev,...) and /tmp as tmpfs, but then we have /var/tmp (which can't
be tmpfs, because it's purpose is to retain the files even across reboots).

I haven't tried it yet, but could a bind-mount be done (e. g. /var/real-tmp
-> /var/tmp) with additional options nosuid,nodev,... (while /var or / is
mounted suid,dev,...)?

Greetings,
 Mike Dornberger


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Boyd Stephen Smith Jr.-3
On Friday 16 January 2009, Mike Dornberger <[hidden email]> wrote
about 'Re: basically security of linux':

>Hi,
>
>just an addition: Often I've seen /home as a separate mount (mounted
>nosuid,nodev,...) and /tmp as tmpfs, but then we have /var/tmp (which
> can't be tmpfs, because it's purpose is to retain the files even across
> reboots).
>
>I haven't tried it yet, but could a bind-mount be done (e. g.
> /var/real-tmp -> /var/tmp) with additional options nosuid,nodev,...
> (while /var or / is mounted suid,dev,...)?
I don't think bind mounts can change the effective permissions.  If I
mount -o bind,nodev /dev /mnt, mount shows the "nodev" option,
but /proc/mounts doesn't and devices like /mnt/null and /mnt/zero work as
expected.

That said, you probably count mkdir /home/var with the right permissions
and then mount -o bind /home/var /var/tmp to get what you are after.

In any case, dpkg installed suid binaries do get scrubbed after they aren't
in use, so you only have to worry about suid binaries you've created
yourself.
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Bernd Eckenfels
In reply to this post by Mike Dornberger
In article <[hidden email]> you wrote:
> /tmp as tmpfs, but then we have /var/tmp (which can't
> be tmpfs, because it's purpose is to retain the files even across reboots).

It is just supposed to hold larger data. No persistence in /var/tmp over
reboots required.

> I haven't tried it yet, but could a bind-mount be done (e. g. /var/real-tmp
> -> /var/tmp) with additional options nosuid,nodev,... (while /var or / is
> mounted suid,dev,...)?

I am mounting /var as noexec, this works most of the time (dpkg has some
problems on install. But since I also run with ro-root, i have a
"pre-install" script which changes both mount options before I use apt).

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Russ Allbery-2
Bernd Eckenfels <[hidden email]> writes:
> In article <[hidden email]> you wrote:

>> /tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because
>> it's purpose is to retain the files even across reboots).
>
> It is just supposed to hold larger data. No persistence in /var/tmp over
> reboots required.

FHS chapter 5
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE:

    The /var/tmp directory is made available for programs that require
    temporary files or directories that are preserved between system
    reboots. Therefore, data stored in /var/tmp is more persistent than
    data in /tmp.

    Files and directories located in /var/tmp must not be deleted when the
    system is booted. Although data stored in /var/tmp is typically
    deleted in a site-specific manner, it is recommended that deletions
    occur at a less frequent interval than /tmp.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: basically security of linux

Sune Vuorela-2
In reply to this post by Boyd Stephen Smith Jr.-3
On 2009-01-16, Boyd Stephen Smith Jr. <[hidden email]> wrote:

> --nextPart7126651.dTOK38xoNi
> Content-Type: text/plain;
>   charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> On Friday 2009 January 16 04:13:10 Michael Loftis wrote:
>>--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus
>><[hidden email]> wrote:
>>> But since some days I mull over a question: What happens  if a user run
>>> a selfcopy from a program with a security hole? I'm afraid he can get
>>> root-rights. Isn't it?
>>In general, no.  This requires an exploitable kernel bug.  That said, there
>>have been some of these in the past, and new ones will likely be discovered
>>in the future, but that's far more rare.  Anything you run as root should
>>only ever come from trusted sources for this reason.
>
> What about hardlinking the suid-root binaries to a hidden location, waiting=
>=20
> for a security hole to be found/fixed, and then running the old binary to=20
> exploit the hole?  Does dpkg handle suid/sgid files so that this is=20
> prevented?

dpkg does strip suid/sgid bits before removing the files - at least when
I tested exactly that a year ago.

/Sune


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]