Re: Security implications of allowing init to re-exec from another path

2006-01-23 Thread Thomas Hood
For the record, we didn't add this feature.  The person who requested it
found that he could bind-mount a different executable over /sbin/init
instead.

-- 
Thomas Hood


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



Re: Security implications of allowing init to re-exec from another path

2006-01-07 Thread Michael Stone

On Thu, Jan 05, 2006 at 09:54:59AM -0200, Henrique de Moraes Holschuh wrote:

Just to make the question a bit more clear for those not reading the bug
report, the real question is, are we causing problems for people who run /
read-only (imagine read-only media) and their security expectations?


So make it configurable.


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



Re: Security implications of allowing init to re-exec from another path

2006-01-05 Thread Henrique de Moraes Holschuh
On Wed, 04 Jan 2006, Thomas Hood wrote:
 In #345741 the submitter has requested that /sbin/init be enhanced
 such that it can be re-executed from another path.  The idea is that
 telinit -e INIT_PROG=/path/to/other/init could be done prior to
 telinit u.
 
 Reasons for introducing this feature are given in the discussion of
 #345741.
 
 Obviously not just anyone can do telinit -e.  So it sounds safe.
 
 Nevertheless the sysvinit maintainers thought it would be a good idea
 to ask here whether anyone sees any security problems arising from
 this feature.

Just to make the question a bit more clear for those not reading the bug
report, the real question is, are we causing problems for people who run /
read-only (imagine read-only media) and their security expectations?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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



Security implications of allowing init to re-exec from another path

2006-01-04 Thread Thomas Hood
Hello security experts.

In #345741 the submitter has requested that /sbin/init be enhanced
such that it can be re-executed from another path.  The idea is that
telinit -e INIT_PROG=/path/to/other/init could be done prior to
telinit u.

Reasons for introducing this feature are given in the discussion of
#345741.

Obviously not just anyone can do telinit -e.  So it sounds safe.

Nevertheless the sysvinit maintainers thought it would be a good idea
to ask here whether anyone sees any security problems arising from
this feature.
-- 
Thomas Hood


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



Re: Security implications of allowing init to re-exec from another path

2006-01-04 Thread martin f krafft
also sprach Thomas Hood [EMAIL PROTECTED] [2006.01.04.1619 +0100]:
 Nevertheless the sysvinit maintainers thought it would be a good
 idea to ask here whether anyone sees any security problems arising
 from this feature.

... sounds like a nice way to infest a system with a trojan, in
addition to kernel modules and other Linux maladities. That is, if
the attacker gets root...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
love is a grave mental disease.
 -- platon


signature.asc
Description: Digital signature (GPG/PGP)


Re: Security implications of allowing init to re-exec from another path

2006-01-04 Thread martin f krafft
also sprach Noah Meyerhans [EMAIL PROTECTED] [2006.01.04.1829 +0100]:
 Yes, but we've already established through years of experience that,
 once an attacker has root access, all bets are off.

Of course. It's not like the attacker couldn't just replace
/sbin/init anyway.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
writing a book is like washing an elephant: there no good place to
 begin or end, and it's hard to keep track of what you've already
 covered.
-- anonymous


signature.asc
Description: Digital signature (GPG/PGP)


Re: Security implications of allowing init to re-exec from another path

2006-01-04 Thread Bernd Eckenfels
martin f krafft [EMAIL PROTECTED] wrote:
 ... sounds like a nice way to infest a system with a trojan, in
 addition to kernel modules and other Linux maladities. That is, if
 the attacker gets root...

However, root can also patch the init image and get the same result. So it
is better if init is actually supporting this, logging it and manipulating
the cmdline so that it is obvious.

Gruss
Bernd


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