Re: Linux security issues as they pertain to CVS

2001-06-01 Thread Greg A. Woods

[ On Friday, June 1, 2001 at 14:02:22 (-0400), Derek R. Price wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> "Greg A. Woods" wrote:
> 
> > The problem is that I see it as if you're trying to say that CVS Pserver
> > plus SSL equals secure.  It most certainly does not.  You have no
> > provable authentication and thus no provable accountability.
> 
> Not on the server side, but it prevents sniffing.

Why bother?  You're gaining so little and adding yet more opportunities
for fatally wrong perceptions to creep in.

I.e. if something's worth doing then it's worth doing right (the first time!).

>  Server certificate checking can
> prove to the client that it got the correct server and this can prevent the user from
> sending her password to an imposter.

Have you implemented that?  Securely (i.e. with real Unix IDs)?

Why not just use SSH?  It can do that already, out-of-the-box even!

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-06-01 Thread Derek R. Price

"Greg A. Woods" wrote:

> The problem is that I see it as if you're trying to say that CVS Pserver
> plus SSL equals secure.  It most certainly does not.  You have no
> provable authentication and thus no provable accountability.

Not on the server side, but it prevents sniffing.  Server certificate checking can
prove to the client that it got the correct server and this can prevent the user from
sending her password to an imposter.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
"My father often told me,
We have servants and machines
in order that our will may be carried out
beyond the reach of our own arms.
Machines are more powerful than servants
and more obedient and less rebellious,
but machines have no judgement
and will not remonstrate with us
when our will is foolish,
and will not disobey us
when our will is evil.
In times and places where people despise the gods,
those most in need of servants have machines,
or choose servants who will behave like machines.
I believe this will continue
until the gods stop laughing."

-Orson Scott Card, "Children of the Mind"




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-31 Thread Ralph Mack

[Greg Woods wrote...]

> By allowing *anyone* to use CVS on your machine you are very nearly
> granting them shell access anyway!  If you do so in a totally
> unaccountable way (i.e. with pserver) then you've just lost the
> integrity (and thus the security) of your repository.

> I.e. CVS cannot guarantee that it will not allow a remote user to
> execute any arbitrary command (and indeed maybe even any arbitrary code
> whatsoever).  There is no inherent security in CVS -- anyone who can
> execute it can probably do anything as the user it executes as.

Perhaps this is what I am missing, then. How does CVS access "very
nearly grant them shell access"? By what mechanism do you see this 
happening? 

Are you assuming that there is a risk worthy of consideration that, 
since no service can be proven to not possess program bugs, and since
some bugs allow code to be injected into programs, any running service 
must be assumed to contain code that was not a part of its original 
design, code "contributed" by a hacker at runtime that may run in any 
account to which the service has access? 

The implication of this would be that no restriction in the design of 
a program is of any significance to security, since no assumptions can 
be made about the actual contents of the running code. The only factor
about a running server that is of any significance is the set of accounts 
to which it is may acquire access during execution. 

Of course, this would apply to the code implementing tunneling services
or ssh or any of a dozen other services as well, no? The fundamental 
paradox of security is that you have to trust someone in order to know 
whom to trust. :-) If we aren't worried about those services, then the
argument is really "I trust these coders not to screw up (perhaps only
because I have to) but not those coders." That's fine; but if that is 
the substance of your argument, it needs to be stated plainly. 

Or is there something more specific to CVS that I am missing? Let us
presume from the outset that reasonable precautions have been made about 
the CVSROOT directory that prevent it from being modified except in a 
local account on the system. This is a known vulnerability, dealt with 
easily enough. Is there something else in CVS that permits its users to
affect files outside of the repository?

Once we're past this point in the discussion, I'll bring up the notion of
what is or isn't considered "acceptable risk" and why.

Ralph A. Mack


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-31 Thread Greg A. Woods

[ On Thursday, May 31, 2001 at 08:06:35 (-0400), Derek R. Price wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> I don't agree.  There are different levels of security, and I will grant that some
> are simply deterrents, but costs are going to be weighed in any security
> implementation decision.

I'm not talking about "levels of security" (indeed all security is
simply a matter of paying enough (in whatever currency is necessary) for
deterrents to reduce the risk of a successful exploit down to an
acceptable level).  There is no such thing as "absolute security" and
that's not what I was trying to imply.

The problem is that I see it as if you're trying to say that CVS Pserver
plus SSL equals secure.  It most certainly does not.  You have no
provable authentication and thus no provable accountability.

The problem with even allowing pserver to continue to exist (with or
without SSL) in its present form (i.e. within CVS) is that it plainly
misleads administrators not trained in understanding trust into having
the wrong impression about the level of security they have actually
implemented if they choose to use it.  This is plainly visible every day
in questions put to this list.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-31 Thread Derek R. Price

"Greg A. Woods" wrote:

> I think you're focusing on some (admittedly important) details without
> looking at the whole picture.  You cannot have security if you don't
> cover *all* of your bases equally!  You also must understand the
> inherent limitations and assumptions built into your client and server
> platforms so that you can establish a true trust path that'll make it
> possible for you to hold your users accountable for their actions.

I don't agree.  There are different levels of security, and I will grant that some
are simply deterrents, but costs are going to be weighed in any security
implementation decision.  My data is not all that valuable to a thief so any
security compromises on my system will likely amount to vandalism which can be
fixed with a small amount of downtime, CVS change backouts, and maybe access to
tape backups.  The analogy would be to putting locks on the door to my apartment
vs. barred windows.  There is a whole different class of people who might walk into
my place if they found the door unlocked vs. those who are actually willing to
break a window to get in.  Since I know I live in a fairly nice neighborhood, I'm
not going to bar the window since I prefer the unmarred view.  Besides, when I lock
myself out I can still break the window myself.  :)

Not barring the windows above the ground floor could extend this analogy - the
windows are still more secure for most purposes than unbarred windows on the first
floor, but the costs of using them are higher since I must ascend at least one
flight of steps to get there.  To go even further, I'm not so paranoid or important
enough to want to paint over the windows and lose the view to protect myself
against snipers...

Just an example, but I wanted to make the point that there are trade-offs in any
security decision (as with most other real-world decisions), which is why
flexibility is my priority here.

I'm not trying to fight any efforts to make CVS more secure, and far from it
I would accept or at least evaluate most patches in this direction, but I wish to
keep a range of security options from simple to use but insecure to tightly secure
and harder to use.  Until someone designs a perfectly secure but still usable
system, which I don't hesitate to say won't ever happen, the system administrator
should be allowed to configure the system to meet her needs.

I'm not attempting to force anybody to use pserver, just providing what I believe
are the facts involved in these particular trade-offs.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
155. I had a life once... now I have a computer and a modem.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-30 Thread Greg A. Woods

[ On Wednesday, May 30, 2001 at 09:23:20 (-0400), Derek R. Price wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> No you don't.  A secure channel only need authenticate the server, possibly
> using an external certificate authority, a la HTTPS.

You cannot have a "secure channel" without some form of authentication.

HTTPS alone does not give you a secure channel.  It might give you a
secret channel, but unless you know an awful lot more about certificates
and SSL than the average person then you do not have any clue as to even
who's machine is on the other end.  Even worse it doesn't tell the
server which *user* is responsible for opening the channel.

That's why I suggested using rsh over an IPsec VPN tunnel.  You could do
the same over an SSH tunnel.  The assumptions of who you have to trust
are more or less the same.

> Which is perfectly fine and possibly even desirable when you, as CVS
> administrator, have no control over the client machine anyhow.  If I have root
> access on the client I could use any login I wished anyhow.  In other words,
> you'd rather know I knew the password you gave me.
> 
> In this case the secure channel should protect you from password sniffers.

I think you're focusing on some (admittedly important) details without
looking at the whole picture.  You cannot have security if you don't
cover *all* of your bases equally!  You also must understand the
inherent limitations and assumptions built into your client and server
platforms so that you can establish a true trust path that'll make it
possible for you to hold your users accountable for their actions.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-30 Thread Derek R. Price

"Greg A. Woods" wrote:

> [ On Tuesday, May 29, 2001 at 09:18:33 (-0500), Thornley, David wrote: ]
> > Subject: RE: Linux security issues as they pertain to CVS
> >
> > Any problems with running pserver over an encrypted channel?  It seems to
> > met that would be just as secure as ssh access (and, of course, just as
> > unsafe - the biggest potential security problems being the guys on both
> > ends of the channel).
>
> That more or less defeats the purpose since you usually have to have a
> real identity to establish a secure channel connection to a server in
> the first place so why not just use that channel for remote job
> execution?  (unless you're talking about an IPsec VPN tunnel, but then
> you've got different issues to worry about)

No you don't.  A secure channel only need authenticate the server, possibly
using an external certificate authority, a la HTTPS.


> CVS pserver on the other hand is under the full and direct control of
> the (or rather *any*) user at the other end so you cannot transfer your
> trust to the client CVS program and you cannot be sure that the person
> at the remote keyboard really is the same "joe" -- there's no secure
> link between the authentication done by the remote client computer to
> allow that user to access it and whatever might be claimed over the
> pserver channel.  Therefore pserver even over a secure channel is not
> itself secure.

Which is perfectly fine and possibly even desirable when you, as CVS
administrator, have no control over the client machine anyhow.  If I have root
access on the client I could use any login I wished anyhow.  In other words,
you'd rather know I knew the password you gave me.

In this case the secure channel should protect you from password sniffers.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Cynic:  Someone who smells the flowers and looks for the casket




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-29 Thread Greg A. Woods

[ On Tuesday, May 29, 2001 at 13:59:09 (-0400), Derek R. Price wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> > Yeah, and there's "nc -l" too.  But is either going to work in a
> > production environment in a development shop?  I doubt it
> 
> Why not?

One problem is that as a sysadmin if I saw "ined-derek" running on my
machine I'd kill it first and ask questions later

> > I'll bet it'll bring any sane and knowledgeable security officer down so
> > hard on your head too that you won't even know what hit you.
> 
> Why?

First off you're offering a new network service, and even if it's only
on the internal network you'd better bet the security guys want to know
what it's all about.

Secondly once they find out what you're actually running they'll be all
over you to accept full responsibilty for everything in your repository
as if you wrote it yourself (since you have no proof that you didn't and
you don't even have any proof of who might have).

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



RE: Linux security issues as they pertain to CVS

2001-05-29 Thread Greg A. Woods

[ On Tuesday, May 29, 2001 at 09:18:33 (-0500), Thornley, David wrote: ]
> Subject: RE: Linux security issues as they pertain to CVS
>
> Any problems with running pserver over an encrypted channel?  It seems to
> met that would be just as secure as ssh access (and, of course, just as
> unsafe - the biggest potential security problems being the guys on both
> ends of the channel).

That more or less defeats the purpose since you usually have to have a
real identity to establish a secure channel connection to a server in
the first place so why not just use that channel for remote job
execution?  (unless you're talking about an IPsec VPN tunnel, but then
you've got different issues to worry about)

With something like SSH the server host must implicitly trust the client
host (which is why it has to establish the identity of the client host),
and the user must implicitly trust both his client and the server --
i.e. every bit of hardware and software between the tips of his fingers
and the magnetic domains on the surface of the server's disks.

The trick is that the owner of the hardware, and the other bits on the
same disk(s) has to trust the user too, and that's where things get fun.

If you've got an end-to-end IPsec tunnel between the CVS server and the
CVS client machine(s) then as a CVS administrator you are probably
literally better off to use rsh and to transfer your trust to the client
computer (i.e. assume that when it says the user "joe" calling then it
is indeed the same user "joe" you would have authorise access to if you
had authenticated him, and that the remote client has itself
authenticated the person at the keyboard and determined him to be "joe")
since in many ways you've implicitly done that already by accepting the
IPsec tunnelled packets in the first place

CVS pserver on the other hand is under the full and direct control of
the (or rather *any*) user at the other end so you cannot transfer your
trust to the client CVS program and you cannot be sure that the person
at the remote keyboard really is the same "joe" -- there's no secure
link between the authentication done by the remote client computer to
allow that user to access it and whatever might be claimed over the
pserver channel.  Therefore pserver even over a secure channel is not
itself secure.

Proper use and understanding of SSH teaches administrators where they've
really placed their trust.  They would be wise to learn from it.

This is even more critially important when the remote client is itself
running on an insecure platform.  If you cannot trust that client system
to run SSH then you most certainly cannot trust it with anything else.
(and that's where intrusion detection becomes important, eg. why
employees are often required to wear photo-ID badges in larger
organisations)

Encryption alone does not give you "security".  Security has four
tightly coupled parts:  Authentication, Authorisation, Integrity,
Privacy; and you cannot call something secure if you take away one of
those components or if you mis-use any one in such a way that you've
disconnected it from the others.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-29 Thread Derek R. Price

"Greg A. Woods" wrote:

> [ On Saturday, May 26, 2001 at 03:07:20 (-0400), Larry Jones wrote: ]
> > Subject: Re: Linux security issues as they pertain to CVS
> >
> > Greg A. Woods writes:
> > >
> > > So, if you don't have root access then how the heck do you propose to
> > > implement CVS Pserver?!?!?!?  (Hint:  you cannot.)
> >
> > Of course you can.  All you need to do is run a private copy of inetd
> > (or whatever replacement you like) as a non-root user, have it run CVS
> > as the same non-root user, and use CVSROOT/passwd to map all valid CVS
> > users to that same non-root system user.  QED.
>
> Yeah, and there's "nc -l" too.  But is either going to work in a
> production environment in a development shop?  I doubt it

Why not?


> I'll bet it'll bring any sane and knowledgeable security officer down so
> hard on your head too that you won't even know what hit you.

Why?

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
170. If you try to fail, and succeed, which have you done?




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-29 Thread Derek R. Price

"Thornley, David" wrote:

> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 25, 2001 7:48 PM
> > To: Mark
> > Cc: CVS Mailing List
> > Subject: Re: Linux security issues as they pertain to CVS
> >
> >
> > The problem is that pserver cannot be made secure.  Literally cannot.
> > It runs on a raw, insecure TCP circuit and is subject to all kinds of
> > man-in-the-middle attacks, connection hijacking, spoofing, etc.
> >
> Any problems with running pserver over an encrypted channel?  It seems to
> met that would be just as secure as ssh access (and, of course, just as
> unsafe - the biggest potential security problems being the guys on both
> ends of the channel).

It depends on the encrypted channel implementation and SSH configuration...
SSH, I know, can be configured to change the encryption keys once an hour
and the like.  I expect some of the channel encryptors are capable of
similar but I don't know the details.

Of course, SSH _could_ be granting shell access to users which is a separate
security issue.

And with both SSH and pserver, the security of the user's local file system
is a limitation since if the ~/.cvspass or the ~/.ssh/* secret keys are
compromised then so is your system.  SSH does allow a password to encrypt
the secret key but there may be no way to guarantee that your users are
using that feature and it's possible that using that feature in a useful
manner is a challenge for some users.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I predict future happiness for Americans if they can prevent the government
from wasting the labors of the people under the pretense of taking care of
them.
- Thomas Jefferson




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-29 Thread Derek R. Price

Mark wrote:

> I think a good explaination of how to run pserver as a non-root
> user would be good to have in the CVS manual.

Like Larry said, as long as all the CVS users in CVSROOT/passwd map to
the same user that the CVS binary is running as, things should work.

Documentation patches happily accepted.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Five days is not too long to wait for a gun.
Five days is not too long to wait for a gun.
Five days is not too long to wait for a gun...

  - Bart Simpson on chalkboard, _The Simpsons_




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



RE: Linux security issues as they pertain to CVS

2001-05-29 Thread Thornley, David



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 25, 2001 7:48 PM
> To: Mark
> Cc: CVS Mailing List
> Subject: Re: Linux security issues as they pertain to CVS
> 
> 
> The problem is that pserver cannot be made secure.  Literally cannot.
> It runs on a raw, insecure TCP circuit and is subject to all kinds of
> man-in-the-middle attacks, connection hijacking, spoofing, etc.
> 
Any problems with running pserver over an encrypted channel?  It seems to
met that would be just as secure as ssh access (and, of course, just as
unsafe - the biggest potential security problems being the guys on both
ends of the channel).
 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-26 Thread Greg A. Woods

[ On Saturday, May 26, 2001 at 03:07:20 (-0400), Larry Jones wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> Greg A. Woods writes:
> > 
> > So, if you don't have root access then how the heck do you propose to
> > implement CVS Pserver?!?!?!?  (Hint:  you cannot.)
> 
> Of course you can.  All you need to do is run a private copy of inetd
> (or whatever replacement you like) as a non-root user, have it run CVS
> as the same non-root user, and use CVSROOT/passwd to map all valid CVS
> users to that same non-root system user.  QED.

Yeah, and there's "nc -l" too.  But is either going to work in a
production environment in a development shop?  I doubt it

I'll bet it'll bring any sane and knowledgeable security officer down so
hard on your head too that you won't even know what hit you.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Larry Jones

Greg A. Woods writes:
> 
> So, if you don't have root access then how the heck do you propose to
> implement CVS Pserver?!?!?!?  (Hint:  you cannot.)

Of course you can.  All you need to do is run a private copy of inetd
(or whatever replacement you like) as a non-root user, have it run CVS
as the same non-root user, and use CVSROOT/passwd to map all valid CVS
users to that same non-root system user.  QED.

-Larry Jones

What a stupid world. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



RE: Linux security issues as they pertain to CVS

2001-05-25 Thread Ralph Mack

Greg,

> Some of the systems that allow this are buggy. Others are broken by 
> design (the system will not let a process permanently discharge its 
> privileged state).  I have made changes to my NetBSD kernel which I 
> believe prevent this from ever happening (at the expense of totally
> eliminating the ill-designed system calls which allow it in the first
> place), but even with those changes I would still not feel safe 
> enough to run CVS as root from inetd (i.e. as a non-anonymous 
> pserver).

This is interesting and you obviously have a lot of experience in this 
area - can you elaborate either here or via private eMail? What system 
calls? What design flaws? Is Linux one of the systems to which you refer? 
I want to understand the mechanism well enough to avoid problems in  
coding wherever possible and to identify and correct problems in other 
folks' code that I encounter. Forewarned is forearmed.

> Worst of all of course is the fact that CVS does not need pserver 
> junk. It works entirely perfectly with any external remote job 
> execution tool.

And any external remote job execution tool will also presumably be 
using setuid() to ensure that it follows the rules because that is
how any daemon does it, right? Its chief advantage is that rje tools 
tend to be more closely examined because the cost (and benefit, I
suppose, to some) of a hole in such a tool is proportionally higher.

However, I am beginning to understand Mr. Price's argument...

It occurs to me that :pserver brings one valuable thing to the table 
that other mechanisms do not. It recognizes that there are two kinds 
of CVS user identity - the user identity through which source changes 
as tracked by CVS, and the operating system user account used to 
determine permissions. 

In other modes of access, the operating system user identity becomes 
the sole user identity tracked by CVS, since there is no other 
identity to be found. This "identity of identities" :-) is a problem 
for many environments. 

System administrators want exclusive control of system user account 
creation. They don't want to deal with user accounts for individual 
CVS users - CVS users come and go at an alarming rate especially on 
open source projects - the road to Linux was paved with good 
intentions - and system administrators aren't equipped to deal with 
user account management at faster than the typical corporate hire/fire 
rate. 

They would rather delegate CVS user identity management to someone 
closely associated with the repository they are serving, someone who 
can't create user accounts or groups, only assign CVS users to 
existing user accounts. CVS users under the same system account have 
the same access to the same files and belong to the same groups. 

However, CVS is open source and can change. An access mode that uses 
something external and well-examined to secure the connection and 
verify account access safely (or better yet provides hooks to do so) 
but separately manages and secures the user identity within CVS would 
be of great value. It could even continue to use the familiar 
CVSROOT/passwd file for the latter role.

Now is that what Mr. Price did or did he do something else?

Ralph


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Greg A. Woods

[ On Friday, May 25, 2001 at 14:51:41 (-0700), Mark wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> It is a large company and a lot of red tape to get anything done.
> I've had all of 45 minutes with the System admin about getting CVS
> setup since I started. He would prefer not running CVS running as
> root, and if root has to run it they would have to own CVS, test it
> and create a whole new line of red tape for
> changes/updates/patches.

I don't see the problem.   CVS via SSH never runs as root.  Just use it!

> I have seen people mention pserver can be run from a non-root used,
> after hours I searching the archives, that web site was the only
> real description on how to do it.

It's trivial (though I don't know if the code has been broken to make it
not actually work in practice)!  Just don't use "root" in the user field
in the /etc/inetd.conf entry for pserver!

You have to have root privileges to set it up, of course.

> I think pserver should be improved on to reach a reasonalble secure
> level or operations (I've leave that to those more experienced in
> security that I).

The problem is that pserver cannot be made secure.  Literally cannot.
It runs on a raw, insecure TCP circuit and is subject to all kinds of
man-in-the-middle attacks, connection hijacking, spoofing, etc.

If you don't want huge amounts of security then use rsh instead of ssh.

However if, as in your case, your security officer won't allow .rhosts
then you need to consider that perhaps you *do* need something
semi-secure and as such your very best choice is SSH (because it already
works and there's a vast body of experience with it).

> I think a good explaination of how to run pserver as a non-root
> user would be good to have in the CVS manual.

Me too!

> I think psever (as root or non-root) may be fine for most
> companies, running behind a firewall and not servicing clients from
> the internet.

Maybe.  Most security problems lie on the inside of the firewall though.
 
-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Greg A. Woods

[ On Friday, May 25, 2001 at 14:38:07 (-0700), Mike Castle wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> On Fri, May 25, 2001 at 04:21:08PM -0400, Greg A. Woods wrote:
> > Worst of all of course is the fact that CVS does not need pserver junk.
> 
> What would you propose as a suitable tools for anonymous cvs access.

An anonymous SSH account, of course.  Pretty easy to set up, even.

However if you wanted something simpler (less heavy-weight), and you
don't care about the security and integrity of the client TCP
connection, then it's pretty easy to set up something like rsh, invoked
from inetd, that does no authentication at all (and which of course
you'd run as some unprivileged user, perhaps in a chroot area with a
statically linked CVS binary through the help of a very tiny and secure
chroot'ing wrapper).  The simplest implementation would be a little
shell script using "nc" (aka netcat) on the client, with inetd on the
server side.  I've not set this up for CVS, but I've done it time and
time again for other similar tools.  Works every time, though provides
litterally no security whatsoever (unless maybe you have TCP Wrappers
integrated into your inetd, as many do these days).

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Greg A. Woods

[ On Friday, May 25, 2001 at 14:51:41 (-0700), Mark wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> I think CVS does need the "pserver junk". I may not always be
> everyones first choice, but it needs to be there and maintained.
> The CVS Administrator does not always have root access, thus may
> not always be able to implement whatever sercurity measures he sees
> fit.

So, if you don't have root access then how the heck do you propose to
implement CVS Pserver?!?!?!?  (Hint:  you cannot.)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Mark


I think CVS does need the "pserver junk". I may not always be
everyones first choice, but it needs to be there and maintained.
The CVS Administrator does not always have root access, thus may
not always be able to implement whatever sercurity measures he sees
fit.

I am a month into a job to set up a CM program with CVS. We
currently don't have CVS running yet. Here's the situation:

It is a large company and a lot of red tape to get anything done.
I've had all of 45 minutes with the System admin about getting CVS
setup since I started. He would prefer not running CVS running as
root, and if root has to run it they would have to own CVS, test it
and create a whole new line of red tape for
changes/updates/patches.

I want to be able to admin CVS as far removed from dependancy on
the Sys Admins as possible. I don't want to submit requests for new
users, wait on Sys Admins to test any patches to CVS I might want
to try out, create repositories as needed, control access to
repositories (unix groups), add new users, switch users about
projects, etc... I want to be free from the 15 levels of approvals
and signoffs and 1 to 4 week turnaround times well you get the
picture.

As for the network environment, .rhosts are not allowed, 80-90% of
the developers do NOT have UNIX logins. They are not running any
ecryption stuff, just plain NIS+. The company network is behind a
firewall and there is a level of trust, as with any company, to
give developers write access to the code. I have read lots of posts
from the archives about security and CVS client/server, and what I
got from them is that it would be great if developers just didn't
need write access, then things would be alot better. But we have to
step out from that and accept some risk so we may develop code and
be a profitable company. That said.

Now what is the least dependant way (minimal dependancy on sysadms
and other support groups) and easiest on the developers  to role
out a client/server CVS solution behind a coporate firewall,
developers do not have/want UNIX logins?

I am going to try a jailed root wrapper that setuid to a non-root
user (no passwd/no shell if possible) and setgid to the group that
owns the repository, in order to run CVS without root. This will
reduce the dependancy of the Sysadms to disk space and the wrapper
program.

I am following the procedure outlined at
http://www.unixtools.org/cvs/server-how-to.html to do this.

Has anyone tryed this? Does it work? I guess will find out.

I have seen people mention pserver can be run from a non-root used,
after hours I searching the archives, that web site was the only
real description on how to do it.

I think pserver should be improved on to reach a reasonalble secure
level or operations (I've leave that to those more experienced in
security that I). But first decide what are your security goals?
Securing root access and the OS? Securing the CVS repository?
Foolproven authentication for changes to the repository? Outside
the trusted users of CVS, and behind a corporate firewall, is
pserver at an acceptable security level, how about pserver not
running as root? What would make it a little better.

I think a good explaination of how to run pserver as a non-root
user would be good to have in the CVS manual.

I think psever (as root or non-root) may be fine for most
companies, running behind a firewall and not servicing clients from
the internet.

Just my thoughts.  Anyone have comments on the non-root jailed root
wrapper to pserver from the web site above?

Cheers,

Mark

> Combining this latter fact with the privilege re-enhancing
> problems and
> you're a sitting duck if you run CVS pserver as root.
> 
> Worst of all of course is the fact that CVS does not need pserver
> junk.
> It works entirely perfectly with any external remote job
> execution tool.
> In that form it is devoid of all responsibilities w.r.t.
> authentication,
> authorisation, integrity and privacy.  The CVS administrator is
> free to
> choose any external RJE tool that meets their security
> requirements in
> combination with the needs of their clients (eg. rsh, ssh,
> stunnel, a
> VPN+rsh, etc.).  Let the security tools do their job and let them
> take
> responsibility for *all* security issues!


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Greg A. Woods

[ On Friday, May 25, 2001 at 10:50:43 (-0400), Larry Jones wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> The problem is that that question is generally unanswerable.  CVS is a
> big program that, if you follow the general advice for setting up
> pserver, runs as root.  The intent is that it only runs as root long
> enough to authenticate the user and then uses setuid() to run as the
> user for the rest of the time so that all of the actions that you expect
> it to perform will be performed as the user.  However, it is extremely
> difficult to prove that it isn't possible to trick it into doing
> something unexpected while it's running as root, and there are lots of
> known ways to trick it into running code as someone else, even root. 

It is impossible to prove mathematically that such a trick cannot be
performed, at least on any normal unix implementation.

Indeed it is possible on many many systems to trick a formerly
privileged process to return to its privileged status, even if that
program tried to be careful to permanently throw away its privileges.
This means any buffer overflow or printf-format bug that tricks the
process into running code that was not originally part of its binary
image can make CVS run as root again, and of course from there it's
trivial to "own" the whole system (chroot or none, even).

Some of the systems that allow this are buggy.  Others are broken by
design (the system will not let a process permanently discharge its
privileged state).  I have made changes to my NetBSD kernel which I
believe prevent this from ever happening (at the expense of totally
eliminating the ill-designed system calls which allow it in the first
place), but even with those changes I would still not feel safe enough
to run CVS as root from inetd (i.e. as a non-anonymous pserver).

Writing privilged code in Unix is very incredibly difficult to do
correctly (writing privileged code that gets its privileges from being a
setuid binary is of course even harder, but not by a whole lot).  CVS is
turned into privileged code if you start it as root from inetd, whether
it wants to be or not.  CVS was not written anywhere nearly that
carefully, never mind with an eye to being run as root.  Indeed if you
build it normally and try to start it from the command line as root it
will rightfully refuse to run!

Combining this latter fact with the privilege re-enhancing problems and
you're a sitting duck if you run CVS pserver as root.

Worst of all of course is the fact that CVS does not need pserver junk.
It works entirely perfectly with any external remote job execution tool.
In that form it is devoid of all responsibilities w.r.t. authentication,
authorisation, integrity and privacy.  The CVS administrator is free to
choose any external RJE tool that meets their security requirements in
combination with the needs of their clients (eg. rsh, ssh, stunnel, a
VPN+rsh, etc.).  Let the security tools do their job and let them take
responsibility for *all* security issues!

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Linux security issues as they pertain to CVS

2001-05-25 Thread Larry Jones

Ralph Mack writes:
> 
> Now it seems to me that when looking at a program I have to ask "What
> actions can this program perform in a setuid() environment?" 

The problem is that that question is generally unanswerable.  CVS is a
big program that, if you follow the general advice for setting up
pserver, runs as root.  The intent is that it only runs as root long
enough to authenticate the user and then uses setuid() to run as the
user for the rest of the time so that all of the actions that you expect
it to perform will be performed as the user.  However, it is extremely
difficult to prove that it isn't possible to trick it into doing
something unexpected while it's running as root, and there are lots of
known ways to trick it into running code as someone else, even root. 
The most obvious of those is to add or modify a $CVSROOT/CVSROOT/passwd
that maps a user with a known password to another user, but there are
lots of more subtle ways, too.

That said, I agree with your main point that one has to determine the
appropriate level of risk.  When running on a mostly-trusted, reasonably
secure intranet, pserver is no more risky than rsh, and probably a lot
easier to set up than ssh.

-Larry Jones

I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs