Re: Disturbing news..

Re: Disturbing news..

[Jesse Pollard]

Keith Owens <kaos@ocs.com.au>
> 
> On Wed, 28 Mar 2001 06:08:15 -0600, 
> Jesse Pollard <jesse@cats-chateau.net> wrote:
> >Sure - very simple. If the execute bit is set on a file, don't allow
> >ANY write to the file. This does modify the permission bits slightly
> >but I don't think it is an unreasonable thing to have.
> 
> man strip
> man objcopy
> man ld

Thought of theses already (well, at least ld...)

strip - not used that much (most executables still have their symbol table
	but could be handled by removing the execute bit, stripping, then
	putting it back. Or just use the ld option -s.
objcopy - copies object files. Object files are not marked executable...
ld	- on other UNIX systems (Cray/IRIX), I think the output file
	(-o) specified is first deleted. Whenever I can cause a link
	error, the output is not marked executable. If the GNU ld doesn't
	delete it first, then it most likely should.

I was expecting shell scripts to be the complaint first... :-)

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 08:15:57AM -0600, Jesse Pollard wrote:
> objcopy - copies object files. Object files are not marked executable...

objcopy copies executable files as well - check the kernel makefiles
for examples.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Disturbing news..

[Jesse Pollard]

Walter Hofmann <snwahofm@mi.uni-erlangen.de>:
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
[snip]
> > Now, if ELF were to be modified, I'd just add a segment checksum
> > for each segment, then put the checksum in the ELF header as well as
> > in the/a segment header just to make things harder. At exec time a checksum
> > verify could (expensive) be done on each segment. A reduced level could be
> > done only on the data segment or text segment. This would at least force
> > the virus to completly read the file to regenerate the checksum.
> 
> So? The virus will just redo the checksum. Sooner or later their will be a
> routine to do this in libbfd and this all reduces to a single additional
> line of code. 

true.

> > That change would even allow for signature checks of the checksum if the
> > signature was stored somewhere else (system binaries/setuid binaries...).
> > But only in a high risk environment. This could even be used for a scanner
> > to detect ANY change to binaries (and fast too - signature check of checksums
> > wouldn't require reading the entire file).
> 
> One sane way to do this is to store the sig on a ro medium and make the
> kernel check the sig of every binary before it is run.

Only for trusted binaries. (extreme paranoia now).
 
> HOWEVER, this means no compilers will work, and you have to delete all
> script languages like perl or python (or make all of them check the
> signature).

Compilers should work normally, the link phase is what would generate
the checksums, though if each object file contained a checksum for the
segment then the interpreters/dynamic loaders would have the choice.

The only applications I see as really needing to check such signatures
are those using PAM. These should do it anyway. The dynamic linking programs
should do so only if they are configured to do so.

> Useless again, IMO.
> 
> > In any case, the problem is limited to one user, even if nothing is done.
> 
> Your best bet is to educate your users.

User eduation is a reasonable substitute as long as they can be directed
to follow the rules.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Jesse Pollard]

Russell King <rmk@arm.linux.org.uk>
> 
> On Wed, Mar 28, 2001 at 08:40:42AM -0600, Jesse Pollard wrote:
> > Now, if ELF were to be modified, I'd just add a segment checksum
> > for each segment, then put the checksum in the ELF header as well as
> > in the/a segment header just to make things harder. At exec time a checksum
> > verify could (expensive) be done on each segment. A reduced level could be
> > done only on the data segment or text segment. This would at least force
> > the virus to completly read the file to regenerate the checksum.
> 
> Checksums don't help that much - virus writers would treat it as "part
> of the set of alterations that need to be made" and then the checksum
> becomes zero protection.
> 
 [ snip of good stuff ]
> Therefore, if you follow good easy system administration techniques, then
> you end up minimising the risk of getting:
> 
> 1. viruses
> 2. trojans
> 3. malicious users
> 
> cracking your system.  If you don't follow these techniques, then you're
> asking for lots of trouble, and no amount of checksumming/signing/etc
> will ever save you.

Absolutely true. The only help the checksumming etc stuff is good for is
detecting the fact afterward by external comparison.

I like MLS for the ability to catch ATTEMPTS to make unauthorized
modification.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[rmk]

Jesse Pollard writes:
> Absolutely true. The only help the checksumming etc stuff is good for is
> detecting the fact afterward by external comparison.

Don't we already have that to some extent?  rpm -ya or rpm -y <package name>
on a RedHat system?  I'm sure that there is a Debian equivalent.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Disturbing news..

[Gerhard Mack]

On Wed, 28 Mar 2001 rmk@arm.linux.org.uk wrote:

> Jesse Pollard writes:
> > Absolutely true. The only help the checksumming etc stuff is good for is
> > detecting the fact afterward by external comparison.
> 
> Don't we already have that to some extent?  rpm -ya or rpm -y <package name>
> on a RedHat system?  I'm sure that there is a Debian equivalent.

http://www.tripwire.com does exactly this afik.	

	Gerhard

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Disturbing news..

[Jesse Pollard]

Russell King <rmk@arm.linux.org.uk>:
> On Wed, Mar 28, 2001 at 08:15:57AM -0600, Jesse Pollard wrote:
> > objcopy - copies object files. Object files are not marked executable...
> 
> objcopy copies executable files as well - check the kernel makefiles
> for examples.

At the time it's copying, the input doesn't need to be executable. That
appears to be a byproduct of a library link.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Jesse Pollard]

Sean Hunter <sean@dev.sportingbet.com>:
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> > 
> 
> Are we not then in the somewhat zen-like state of having an "rm" which can't
> "rm" itself without needing to be made non-executable so that it can't execute?

We've been in that state for a long time... (carefull updating that libc.so
file... can't overwrite/delete without having some REAL problems show up.)

It just calls for some carefull activity. If rm is being replaced, first
rename it; then put new one in place; chmod old; delete old. It is directly
comparable to the libc.so update procedure.

I should have left off the "very simple" remark.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> 
> Even easier method - remove the write permission bits from all executable
> files, and don't do the unsafe thing of running email/web browsers/other
> user-type stuff as user root.
> 
> If it still worries you that root can write to files without the 'w' bit
> set, modify the capabilities of the system to prevent it (there is a bit
> that can be set which will remove this ability for all new processes).

How about just adding MLS ... :-)

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Jesse Pollard]

> 
> 
> 
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
> 
> > >Any idea?
> > 
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> 
> And how exactly does this help?
> 
> fchmod (fd, 0666);
> fwrite (fd, ...);
> fchmod (fd, 0777);

By itself it doesn't - but if you also don't have user/group/world rw and
don't own the file, you can't do anything to it.

It's only there to reduce accidents. If you want to go full out,
remove the symbols from the file.

Now, if ELF were to be modified, I'd just add a segment checksum
for each segment, then put the checksum in the ELF header as well as
in the/a segment header just to make things harder. At exec time a checksum
verify could (expensive) be done on each segment. A reduced level could be
done only on the data segment or text segment. This would at least force
the virus to completly read the file to regenerate the checksum.

That change would even allow for signature checks of the checksum if the
signature was stored somewhere else (system binaries/setuid binaries...).
But only in a high risk environment. This could even be used for a scanner
to detect ANY change to binaries (and fast too - signature check of checksums
wouldn't require reading the entire file).

In any case, the problem is limited to one user, even if nothing is done.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 08:40:42AM -0600, Jesse Pollard wrote:
> Now, if ELF were to be modified, I'd just add a segment checksum
> for each segment, then put the checksum in the ELF header as well as
> in the/a segment header just to make things harder. At exec time a checksum
> verify could (expensive) be done on each segment. A reduced level could be
> done only on the data segment or text segment. This would at least force
> the virus to completly read the file to regenerate the checksum.

Checksums don't help that much - virus writers would treat it as "part
of the set of alterations that need to be made" and then the checksum
becomes zero protection.

Your system binaries are safe from the virus (from my understanding of the
poor writeup) if you are sensible about your system - ie, don't run stuff
as the root user, don't login as root, ensure that your binaries are owned
by root etc.

If users have their own binaries, then they should take adequate care
over them (find ~ -type f -perm +111 | xargs chmod a-w) to ensure that
they are not writable (this applies to your argument as well).

Once you're in this situation:

1. Users can't write to their executables without first chmod'ing them.
   (won't take long for a virus writer to get the idea that they should
   chmod +w them first).

2. If a user binary becomes infected, only people able to run that binary
   also become infected.  Certainly root should under no circumstances
   run any program which a user has compiled - the user may have some
   nice code in there which creates another root user in /etc/passwd
   with no password entry.

3. Since you're only running system programs as root (and by that I mean
   stuff for administration, not stuff like mail clients, news readers
   etc), your system binaries should not become infected.

Therefore, if you follow good easy system administration techniques, then
you end up minimising the risk of getting:

1. viruses
2. trojans
3. malicious users

cracking your system.  If you don't follow these techniques, then you're
asking for lots of trouble, and no amount of checksumming/signing/etc
will ever save you.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Disturbing news..

[Walter Hofmann]

On Wed, 28 Mar 2001, Jesse Pollard wrote:

> By itself it doesn't - but if you also don't have user/group/world rw and
> don't own the file, you can't do anything to it.

This is all completely useless. Why not remove world rw permissions in the
first place. If the admin isn't even able to write a cron job that does
this, all help is lost.

> It's only there to reduce accidents. If you want to go full out,
> remove the symbols from the file.

Just as useless.

> Now, if ELF were to be modified, I'd just add a segment checksum
> for each segment, then put the checksum in the ELF header as well as
> in the/a segment header just to make things harder. At exec time a checksum
> verify could (expensive) be done on each segment. A reduced level could be
> done only on the data segment or text segment. This would at least force
> the virus to completly read the file to regenerate the checksum.

So? The virus will just redo the checksum. Sooner or later their will be a
routine to do this in libbfd and this all reduces to a single additional
line of code. 

> That change would even allow for signature checks of the checksum if the
> signature was stored somewhere else (system binaries/setuid binaries...).
> But only in a high risk environment. This could even be used for a scanner
> to detect ANY change to binaries (and fast too - signature check of checksums
> wouldn't require reading the entire file).

One sane way to do this is to store the sig on a ro medium and make the
kernel check the sig of every binary before it is run.

HOWEVER, this means no compilers will work, and you have to delete all
script languages like perl or python (or make all of them check the
signature).

Useless again, IMO.

> In any case, the problem is limited to one user, even if nothing is done.

Your best bet is to educate your users.

Walter

Re: Ideas for the oom problem

[Jonathan Morton]

I'm going to be gentle here and try to point out where your suggestions are
flawed...

>a. don't kill any task with a uid < 100

Suppose your system daemon springs a leak?  It will have to be killed
eventually, however system daemons can sensibly be given a little "grace".
Also, the UIDs used by a system daemon vary from system to system.

>b. if uid between 100 to 500 or CAP-SYS equivalent enabled
>	set it too a lower priority, so if it is at fault it will happen
>slower
>            giving more time before the system collapses

Not slowly enough.  When your system is thrashing, the CPU is the resource
under least pressure, so "nice" values and priorities have virtually zero
effect.  In any case, under OOM conditions the system has *already*
collapsed and we *have* to kill something for the system to keep running.

>c.  if a task is nice'd then immediately put the task too sleep, and schedule
>all code / data too be swapped out, or thrown away as appropiate. do not
>reschedule the task too continue until memory is available

In OOM conditions there is no swap space left to do what you suggest.  This
is a sensible solution for when thrashing is the only problem...

>d. kill any normal user interactive tasks that is started during a memory
>crisis.

Define "memory crisis".  However, this is a relatively sensible solution.

>allocate a pool of memory at system start up that is too be released to the
>memory pool when the system is in a memory crisis. This will reduce system
>swapping, and allow the system too stablize slightly

One of my patches already tries to do this, in a way.  It doesn't yet
provide a hard barrier, but it does prevent applications from hogging the
entire memory on the system (at least, without expending some effort into
it).

>report any task asking for large pool of memory while the system is in
>oom crisis. if uid > 500 and was started from an interactive shell it should
>be killed.

See above.  malloc() fails, which tells the application there is no more
memory in the system.  A well-written application will respond to this and
use more memory-conservative techniques.  A poorly-written application will
segfault.  End Of Problem.  Now to make memory accounting work properly so
these tests are reliable...

>when the crisis is ended, re-adquire the memory pool for later usage.

It is never given up, except when it is needed by the kernel itself (eg. to
swap in pages or (in the absence of true memory accounting) to provide COW
space.

>Prong 3 providing  information about oom crisis too user land
>
>create /proc/vm/oom_crisis this would be readonly file owned by root it would
>report if the system is in crisis and the uid of any process that is asking
>for large amounts of ram while the system
>is in crisis.

This kind of information is already available using /proc - applications
just have to look int he right places.

>create a SIGDANGER handler that is sent out too all tasks that have
>registered a handler when the kernel enters oom_kill, give these tasks a high
>priority access too system resources.

This is a fairly good idea, why does it look so familiar?  :)  SIGDANGER
would be sent to all processes when memory availablility goes below a
threshold, ie. when there is still enough memory left to handle the
situation.  The default handler would be a no-op, preserving compatibility.
However, the notion of "high priority access to resources" is not currently
feasible (or necessary).

>this would enable user land programs too deal with the situation with out
>continuous polling free ram/swap. They could email/page sysadmin and user
>about the crisis and add additional swap resources and kill any know  non
>essential tasks. and probe system for possible broken tasks, such as
>netscape-common tasks not connected too netscape client, at least i have been
>known too find these when netscape crashes.

Interesting applications for this signal.  However, this is entirely a
userspace issue as to what to do with the signal - the kernel's job is to
provide it (if we decide to, that is).

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ 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-----

Disturbing news..

[Shawn Starr]

http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh

Isn't it time to change the ELF format to stop this crap?

Shawn.

Re: Disturbing news..

[Matti Aarnio]

On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> Date:	Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> From:	Shawn Starr <spstarr@sh0n.net>
> To:	<linux-kernel@vger.kernel.org>
> Subject: Disturbing news..
> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> Isn't it time to change the ELF format to stop this crap?
> Shawn.

	Why ?   "Double-click on attachment to run it" is typical
		M$ client stupidity -- and the reason why there
		are so many things that can mail themselves around.

	Changeing ELF-format would be comparable to what M$ did when
	they met the first Word macro viruses -- they changed the
	script language inside the Word...   What good did that do ?
	Did it harm people ?  You bet...


	You are downloading binaries off the net, and not compiling
	from the sources ?  (Yes, we all do that.  This is why folks
	these days carry PGP signatures at the RPM packages.)


	So, the program modifies ELF format executables by rewriting
	some instructions in the beginning (propably to map-in the virus
	code proper with X-bit on), and tags itself (PIC presumably) at
	the end of the file.



	Another issue is "safe conduct" practice of installing binaries
	with minimum privileges (ok, granted that for e.g. RPMs that
	usually means root), and *never* running them with undue levels
	of privileges -- not even as the owner of said executables.



	Ok, granted that we have dangers of getting arbitrary BAD programs
	into our systems, how can we combat that ?   Virus-scanners
	(as much good as they could do..) don't really work in UNIX
	environments where "small things" like intercept of every
	exec(), and open() via privileged program (scanner) is not
	available feature. (I think doing it by passing a AF_UNIX
	message with fd + flags to registered server, expecting answer
	for the open() -- this would happen *after* the file open is
	done with user privileges, but before the call returns.)
	(Trapping open() so that shared-libraries could be scanned.)

	There could be, I think, a method for doing such intercepts,
	which could be used by security scanners to implement some
	sense of security in Linux-like systems.

	Is it good enough, e.g. when some file is multiply-mapped to
	shared programs, and application rewrites parts of the file ?
	Can it detect that kind of multi-mapped writing-sharing ?

	Can such system be made fast ?  (Scanner becomes performance
	bottle-neck.)


	How about PROPER Orange Book B-level security ?
	E.g. NSA trusted-linux ?


/Matti Aarnio

Re: Disturbing news..

[Shawn Starr]

Well, why can't the ELF loader module/kernel detect or have some sort of
restriction on modifying other/ELF binaries including itself from changing
the Entry point?

There has to be a way stop this. WHY would anyone want to modify the entry
point anyway? (there may be some reasons but I really dont know what).
Even if it's user level, this cant affect files with root permissions
(unless root is running them or suid).

Any idea?

On Wed, 28 Mar 2001, Matti Aarnio wrote:

> On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> > Date:	Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> > From:	Shawn Starr <spstarr@sh0n.net>
> > To:	<linux-kernel@vger.kernel.org>
> > Subject: Disturbing news..
> >
> > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> > Isn't it time to change the ELF format to stop this crap?
> > Shawn.
>
> 	Why ?   "Double-click on attachment to run it" is typical
> 		M$ client stupidity -- and the reason why there
> 		are so many things that can mail themselves around.
>
> 	Changeing ELF-format would be comparable to what M$ did when
> 	they met the first Word macro viruses -- they changed the
> 	script language inside the Word...   What good did that do ?
> 	Did it harm people ?  You bet...
>
>
> 	You are downloading binaries off the net, and not compiling
> 	from the sources ?  (Yes, we all do that.  This is why folks
> 	these days carry PGP signatures at the RPM packages.)
>
>
> 	So, the program modifies ELF format executables by rewriting
> 	some instructions in the beginning (propably to map-in the virus
> 	code proper with X-bit on), and tags itself (PIC presumably) at
> 	the end of the file.
>
>
>
> 	Another issue is "safe conduct" practice of installing binaries
> 	with minimum privileges (ok, granted that for e.g. RPMs that
> 	usually means root), and *never* running them with undue levels
> 	of privileges -- not even as the owner of said executables.
>
>
>
> 	Ok, granted that we have dangers of getting arbitrary BAD programs
> 	into our systems, how can we combat that ?   Virus-scanners
> 	(as much good as they could do..) don't really work in UNIX
> 	environments where "small things" like intercept of every
> 	exec(), and open() via privileged program (scanner) is not
> 	available feature. (I think doing it by passing a AF_UNIX
> 	message with fd + flags to registered server, expecting answer
> 	for the open() -- this would happen *after* the file open is
> 	done with user privileges, but before the call returns.)
> 	(Trapping open() so that shared-libraries could be scanned.)
>
> 	There could be, I think, a method for doing such intercepts,
> 	which could be used by security scanners to implement some
> 	sense of security in Linux-like systems.
>
> 	Is it good enough, e.g. when some file is multiply-mapped to
> 	shared programs, and application rewrites parts of the file ?
> 	Can it detect that kind of multi-mapped writing-sharing ?
>
> 	Can such system be made fast ?  (Scanner becomes performance
> 	bottle-neck.)
>
>
> 	How about PROPER Orange Book B-level security ?
> 	E.g. NSA trusted-linux ?
>
>
> /Matti Aarnio
>
>

Re: Disturbing news..

[Jesse Pollard]

On Wed, 28 Mar 2001, Shawn Starr wrote:
>Well, why can't the ELF loader module/kernel detect or have some sort of
>restriction on modifying other/ELF binaries including itself from changing
>the Entry point?
>
>There has to be a way stop this. WHY would anyone want to modify the entry
>point anyway? (there may be some reasons but I really dont know what).
>Even if it's user level, this cant affect files with root permissions
>(unless root is running them or suid).
>
>Any idea?

Sure - very simple. If the execute bit is set on a file, don't allow
ANY write to the file. This does modify the permission bits slightly
but I don't think it is an unreasonable thing to have.

>
>On Wed, 28 Mar 2001, Matti Aarnio wrote:
>
>> On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
>> > Date:	Wed, 28 Mar 2001 01:16:02 -0500 (EST)
>> > From:	Shawn Starr <spstarr@sh0n.net>
>> > To:	<linux-kernel@vger.kernel.org>
>> > Subject: Disturbing news..
>> >
>> > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
>> > Isn't it time to change the ELF format to stop this crap?
>> > Shawn.
>>
>> 	Why ?   "Double-click on attachment to run it" is typical
>> 		M$ client stupidity -- and the reason why there
>> 		are so many things that can mail themselves around.
>>
>> 	Changeing ELF-format would be comparable to what M$ did when
>> 	they met the first Word macro viruses -- they changed the
>> 	script language inside the Word...   What good did that do ?
>> 	Did it harm people ?  You bet...
>>
>>
>> 	You are downloading binaries off the net, and not compiling
>> 	from the sources ?  (Yes, we all do that.  This is why folks
>> 	these days carry PGP signatures at the RPM packages.)
>>
>>
>> 	So, the program modifies ELF format executables by rewriting
>> 	some instructions in the beginning (propably to map-in the virus
>> 	code proper with X-bit on), and tags itself (PIC presumably) at
>> 	the end of the file.
>>
>>
>>
>> 	Another issue is "safe conduct" practice of installing binaries
>> 	with minimum privileges (ok, granted that for e.g. RPMs that
>> 	usually means root), and *never* running them with undue levels
>> 	of privileges -- not even as the owner of said executables.
>>
>>
>>
>> 	Ok, granted that we have dangers of getting arbitrary BAD programs
>> 	into our systems, how can we combat that ?   Virus-scanners
>> 	(as much good as they could do..) don't really work in UNIX
>> 	environments where "small things" like intercept of every
>> 	exec(), and open() via privileged program (scanner) is not
>> 	available feature. (I think doing it by passing a AF_UNIX
>> 	message with fd + flags to registered server, expecting answer
>> 	for the open() -- this would happen *after* the file open is
>> 	done with user privileges, but before the call returns.)
>> 	(Trapping open() so that shared-libraries could be scanned.)
>>
>> 	There could be, I think, a method for doing such intercepts,
>> 	which could be used by security scanners to implement some
>> 	sense of security in Linux-like systems.
>>
>> 	Is it good enough, e.g. when some file is multiply-mapped to
>> 	shared programs, and application rewrites parts of the file ?
>> 	Can it detect that kind of multi-mapped writing-sharing ?
>>
>> 	Can such system be made fast ?  (Scanner becomes performance
>> 	bottle-neck.)
>>
>>
>> 	How about PROPER Orange Book B-level security ?
>> 	E.g. NSA trusted-linux ?
>>
>>
>> /Matti Aarnio
>>
>>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: Disturbing news..

[Ben Ford]

Jesse Pollard wrote:

> On Wed, 28 Mar 2001, Shawn Starr wrote:
> 
>> Well, why can't the ELF loader module/kernel detect or have some sort of
>> restriction on modifying other/ELF binaries including itself from changing
>> the Entry point?
>> 
>> There has to be a way stop this. WHY would anyone want to modify the entry
>> point anyway? (there may be some reasons but I really dont know what).
>> Even if it's user level, this cant affect files with root permissions
>> (unless root is running them or suid).
>> 
>> Any idea?
> 
> 
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.
> 
What a pain in the ass when you are writing / updating a shell script . 
. . .

Re: Disturbing news..

[Walter Hofmann]

On Wed, 28 Mar 2001, Jesse Pollard wrote:

> >Any idea?
> 
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

And how exactly does this help?

fchmod (fd, 0666);
fwrite (fd, ...);
fchmod (fd, 0777);

Walter

Re: Disturbing news..

[Simon Williams]

In message <Pine.GSO.3.96.1010328144551.7198A-100000@laertes>, Walter
Hofmann <snwahofm@mi.uni-erlangen.de> writes
>
>
>On Wed, 28 Mar 2001, Jesse Pollard wrote:
>
>> >Any idea?
>> 
>> Sure - very simple. If the execute bit is set on a file, don't allow
>> ANY write to the file. This does modify the permission bits slightly
>> but I don't think it is an unreasonable thing to have.
>
>And how exactly does this help?
>
>fchmod (fd, 0666);
>fwrite (fd, ...);
>fchmod (fd, 0777);
>

I think their point was that a program could only change permissions
of a file that was owned by the same owner.  If a file is owned by a
different user & has no write permissions for any user, the program
can't modify the file or it's permissions.

Sounds like a good plan to me.


-- 
Simon Williams

Re: Disturbing news..

[Olivier Galibert]

On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
> I think their point was that a program could only change permissions
> of a file that was owned by the same owner.  If a file is owned by a
> different user & has no write permissions for any user, the program
> can't modify the file or it's permissions.

You mean, you usually have write permissions for other than the owner
on executable files?

Let me reformulate that.  You usually have write permissions for other
than the owner, and not only on some special, untrusted log files (I'm
talking files, here, not device nodes)?  What's your umask, 0?


> Sounds like a good plan to me.

PEBCAK.  Unix security is not designed with dumb "administrators" in
mind, nor should be.  User friendly is good.  Luser friendly isn't,
it's either dumbing down or unnecessarily restrictive.

  OG, who waits for the first insmod-ing "virus"

Re: Disturbing news..

[Simon Williams]

In message <20010328100440.A5941@zalem.puupuu.org>, Olivier Galibert
<galibert@pobox.com> writes
>On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
>> I think their point was that a program could only change permissions
>> of a file that was owned by the same owner.  If a file is owned by a
>> different user & has no write permissions for any user, the program
>> can't modify the file or it's permissions.
>
>You mean, you usually have write permissions for other than the owner
>on executable files?
>
>Let me reformulate that.  You usually have write permissions for other
>than the owner, and not only on some special, untrusted log files (I'm
>talking files, here, not device nodes)?  What's your umask, 0?
>

Firstly, I'm relatively new to Linux (only about 3 yrs experience) &
don't claim to be an expert.  Secondly, I don't think I stated my point
very clearly.

No, I don't have write permissions set on an executable for any user
other than the owner.

What I meant was that if a file is owned by root with permissions of,
say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
run as a non-root user cannot modify it or change the permissions to
7 (rwx).

>
>> Sounds like a good plan to me.
>
>PEBCAK.  Unix security is not designed with dumb "administrators" in
>mind, nor should be.  User friendly is good.  Luser friendly isn't,
>it's either dumbing down or unnecessarily restrictive.
>

I completely agree (even with the PEBCAK part :)).  UNIX security on
corporate networks or public-facing systems should be left to experts.
I, on the other hand, am a home-user trying to learn how Linux works &
how to secure it, I don't pretend to be an expert.

My policy is to give necessary permissions & no more.  I would set the
aforementioned permissions on the main system binaries which would allow
other users to get on with what they need to do without being able to
affect the workspaces of other users, only their own.

I'm open to contructive criticism on this.


-- 
Simon Williams

Re: Disturbing news..

[Ben Ford]

Simon Williams wrote:

> In message <20010328100440.A5941@zalem.puupuu.org>, Olivier Galibert
> <galibert@pobox.com> writes
> 
>> On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
>> 
>>> I think their point was that a program could only change permissions
>>> of a file that was owned by the same owner.  If a file is owned by a
>>> different user & has no write permissions for any user, the program
>>> can't modify the file or it's permissions.
>> 
>> You mean, you usually have write permissions for other than the owner
>> on executable files?
>> 
>> Let me reformulate that.  You usually have write permissions for other
>> than the owner, and not only on some special, untrusted log files (I'm
>> talking files, here, not device nodes)?  What's your umask, 0?
>> 
> 
> Firstly, I'm relatively new to Linux (only about 3 yrs experience) &
> don't claim to be an expert.  Secondly, I don't think I stated my point
> very clearly.
> 
> No, I don't have write permissions set on an executable for any user
> other than the owner.
> 
> What I meant was that if a file is owned by root with permissions of,
> say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
> run as a non-root user cannot modify it or change the permissions to
> 7 (rwx).

There are two problems I see here.  First, there are several known ways 
to elevate privileges.  If a virus can elevate privileges, then it owns 
you.  Second, this is a multi-OS virus.  If you dual-boot into Windows,  
any ELF files accessible can be infected.  With this one, that isn't a 
prob, but when somebody codes in an ext2 driver to their virus, then 
we've got issues.

-b

Re: Disturbing news..

[Helge Hafting]

Ben Ford wrote:
> 

> There are two problems I see here.  First, there are several known ways
> to elevate privileges.  
Fixable, except from guessing the root password which is hard.

> If a virus can elevate privileges, then it owns
> you.  Second, this is a multi-OS virus.  If you dual-boot into Windows,
> any ELF files accessible can be infected.  With this one, that isn't a
> prob, but when somebody codes in an ext2 driver to their virus, then
> we've got issues.

And the only cure then is not make your linux fs accessible from
windows.  I.e. not on a disk for which windows have a driver
installed.  Preferably not the same computer.

Or simply "don't run untrusted executables under windows".  Do
so in linux only, where protection applies.  Do anybody ever
_need_ to run a program they got in the mail?

Helge Hafting

Re: Disturbing news..

[Olivier Galibert]

On Wed, Mar 28, 2001 at 04:49:26PM +0100, Simon Williams wrote:
> What I meant was that if a file is owned by root with permissions of,
> say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
> run as a non-root user cannot modify it or change the permissions to
> 7 (rwx).

It's already the case that a file owned by user A cannot have its
rights changed by user B.  Also, if the write permission is not set,
you can't modify the file.  That's the basic unix security model.  Of
course, if you're root all best are off, root is god.  For those who
con't like that, there are things like capabilities and MAC.  But they
are _really_ hard to setup correctly.

What they are talking about is to have the x bit cancel the w bit,
i.e. make the rwx files unwritable.  Fixing the symptoms, you know...


> My policy is to give necessary permissions & no more.

This is not a bad policy.  Removing read permissions can make fixing
problems a pain, though (what, no gdb/strace of system executables?).


> I would set the
> aforementioned permissions on the main system binaries which would allow
> other users to get on with what they need to do without being able to
> affect the workspaces of other users, only their own.

Well, the main system binaries are already that way (r-xr-xr-x or
rwxr-xr-x, which when root-owned are equivalent).  I don't see your
point.

  OG.

Re: Disturbing news..

[Keith Owens]

On Wed, 28 Mar 2001 06:08:15 -0600, 
Jesse Pollard <jesse@cats-chateau.net> wrote:
>Sure - very simple. If the execute bit is set on a file, don't allow
>ANY write to the file. This does modify the permission bits slightly
>but I don't think it is an unreasonable thing to have.

man strip
man objcopy
man ld

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

Even easier method - remove the write permission bits from all executable
files, and don't do the unsafe thing of running email/web browsers/other
user-type stuff as user root.

If it still worries you that root can write to files without the 'w' bit
set, modify the capabilities of the system to prevent it (there is a bit
that can be set which will remove this ability for all new processes).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Disturbing news..

[Sean Hunter]

On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.
> 

Are we not then in the somewhat zen-like state of having an "rm" which can't
"rm" itself without needing to be made non-executable so that it can't execute?

Sean

Re: Disturbing news..

[john slee]

[cc list trimmed]

On Wed, Mar 28, 2001 at 03:10:08PM +0100, Sean Hunter wrote:
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> >
> 
> Are we not then in the somewhat zen-like state of having an "rm" which can't
> "rm" itself without needing to be made non-executable so that it can't execute?

aiiiieee, my head hurts now, thanks :(

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Disturbing news..

[Jonathan Lundell]

 john slee <indigoid@higherplane.net> says:

>On Wed, Mar 28, 2001 at 03:10:08PM +0100, Sean Hunter wrote:
>> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
>> > Sure - very simple. If the execute bit is set on a file, don't allow
>> > ANY write to the file. This does modify the permission bits slightly
>> > but I don't think it is an unreasonable thing to have.
>> >
>>
>> Are we not then in the somewhat zen-like state of having an "rm" which can't
>> "rm" itself without needing to be made non-executable so that it can't execute?
>
>aiiiieee, my head hurts now, thanks :(

It shouldn't. rm is not prevented from removing an unwriteable file (though it complains by default). Directory permissions control operations on links.

-- 
/Jonathan Lundell.

Re: Disturbing news..

[Dr. Kelsey Hudson]

On Wed, 28 Mar 2001, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

Oh, honestly! Think about what you are saying here:

What if you are developing something in an interpereted language such as
perl or a shell script, where you *directly modify the executable file*?

No, this won't work...Not wwithout being annoying as hell.

Re: Disturbing news..

[Horst von Brand]

Shawn Starr <spstarr@sh0n.net> said:
> Well, why can't the ELF loader module/kernel detect or have some sort of
> restriction on modifying other/ELF binaries including itself from changing
> the Entry point?

Because there are quite valid reasons for "normal" programs (e.g., ld(1)
and other binary-futzing tools) to do so. No, I don't want a paranoic
system where I (regular user) can't do this to my own files using a random
binary editor. An executable is just a normal file in Unix, can't get
around this without seriously breaking lots of stuff.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Disturbing news..

[Helge Hafting]

Shawn Starr wrote:
> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> 
> Isn't it time to change the ELF format to stop this crap?
> 
Nothing to worry about.
A sane distribution have all executables installed read-only
and owned by root or some non-user.  

Email appliacations and file browsers etc. are run as normal
users.  So, even if the user stupidly run this mysterious
program he got in the mail - what happens?

It search for all ELF executables in the system and find
it can open none!  They are not writeable, and the
user don't own them so the bad program cannot change
permissions in order to modify the executables either.

About the only "danger" here is messing with a developer's
program being developed, but he can recompile it
and loose the virus that way.  And a developer wouldn't
trust a program he got in the mail in the first place.
Those dumb enough don't have any writeable executables.

Helge Hafting

Re: Disturbing news..

[Alexander Viro]

On Wed, 28 Mar 2001, Shawn Starr wrote:

> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> 
> Isn't it time to change the ELF format to stop this crap?

<shrug> If you run untrusted binaries - you are screwed.  If you run
them as root - all users on your system are screwed.  If your MUA
(or browser, etc.) can run untrusted code - see above.  If you have
a dual-boot system and one of the OSes is compromised - all of them
are.  Nothing to do about that.  What's new here?  Don't be an idiot 
nd don't use crapware...

Re: Disturbing news..

[Romano Giannetti]

Notice: this is my first post to l-k since some bug report as old as 0.99...
so please be kind, don't beat me to hard.

On Wed, Mar 28, 2001 at 08:25:46AM -0500, Alexander Viro wrote:
 
> <shrug> If you run untrusted binaries - you are screwed.  If you run
> them as root - all users on your system are screwed.  If your MUA
> (or browser, etc.) can run untrusted code - see above. 

Too true. 

But with the new VFS semantics, wouldn't be possible for a MUA to make a
thing like the following: 

spawn a process with a private namespace. Here a minimun subset of the
"real" tree (maybe all / except /dev) is mounted readonly. The private /tmp
and /home/user are substituted by read-write directory that are in the
"real" tree /home/user/mua/fakehome and /home/user/mua/faketmp. In this
private namespace, run the "untrusted" binary. 

Now the binary can do much less harm than before, or am I missing something?
It have no access to real user data, but can use the system library and
services without changing anything in the system. 

Having the read-only flag per vfs-mount is the only kernel-related thing
here, I think; all the rest is simply user-space spice :-). 

Have a nice day,
                   Romano 


-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132

Re: Disturbing news..

[Bill Rugolsky Jr.]

On Wed, Mar 28, 2001 at 04:32:44PM +0200, Romano Giannetti wrote:
> But with the new VFS semantics, wouldn't be possible for a MUA to make a
> thing like the following: 
> 
> spawn a process with a private namespace. Here a minimun subset of the
> "real" tree (maybe all / except /dev) is mounted readonly. The private /tmp
> and /home/user are substituted by read-write directory that are in the
> "real" tree /home/user/mua/fakehome and /home/user/mua/faketmp. In this
> private namespace, run the "untrusted" binary. 

Possible and desirable.  You have to turn off access to all the other
dangerous namespaces though, like socket() and shmat(), and make sure
that nosuid and devices are handled properly. Done right, the only thing
that untrusted code can do is consume a little memory, CPU, and disk,
but that's why there are limits and a scheduler. :-)

One might even want to add back limited access to those other namespaces
by implementing a filesystem interface, ala Plan-9/Inferno.

Regards,

   Bill Rugolsky

Re: Disturbing news..

[Alexander Viro]

On Wed, 28 Mar 2001, Romano Giannetti wrote:

> Now the binary can do much less harm than before, or am I missing something?
> It have no access to real user data, but can use the system library and
> services without changing anything in the system. 

You mean, like mailbombing the living hell out of somebody? Or playing
interesting games with sending signals all over the place...

Re: Disturbing news..

[Romano Giannetti]

On Wed, Mar 28, 2001 at 09:57:47AM -0500, Alexander Viro wrote:
> 
> On Wed, 28 Mar 2001, Romano Giannetti wrote:
> 
> > Now the binary can do much less harm than before, or am I missing something?
> > It have no access to real user data, but can use the system library and
> > services without changing anything in the system. 
> 
> You mean, like mailbombing the living hell out of somebody? Or playing
> interesting games with sending signals all over the place...

Yes, I was sure there were doors left, but --- it has no access to the
bookmark list of user, and can kill just user processes... that was what I
meant with "less harm" (never say never, I know...). 

           Romano 

-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132