Hi,
Did you try c) already? Did it work effectively?
No not yet.
Still in research/checking out the options mode.
but c) is not OpenSSH right?
Correct.
Sorry I forgot to mention that is my options list.
I've only skimmed over the lisence so far. It will require
a closer to make a proper assesment.
Hi,
Did you try c) already? Did it work effectively?
No not yet.
Still in research/checking out the options mode.
but c) is not OpenSSH right?
Correct.
Sorry I forgot to mention that is my options list.
I've only skimmed over the lisence so far. It will require
a closer to make a proper assesment.
* Rudi Starcevic schrieb am 21.10.03 um 16:53 Uhr:
> Hi,
>
> > Our rbash shells don't have access to vi ... or much else! Their
> > path is set to "/usr/local/lib/rbash-bin/" and that directory has
> > sym-links to a few selected binaries.
> >
> > Still I don't regard the rbash setup as secure.
* Rudi Starcevic schrieb am 21.10.03 um 16:53 Uhr:
> Hi,
>
> > Our rbash shells don't have access to vi ... or much else! Their
> > path is set to "/usr/local/lib/rbash-bin/" and that directory has
> > sym-links to a few selected binaries.
> >
> > Still I don't regard the rbash setup as secure.
> To sumerize the options I've found so far:
>
> a) PAM chroot
> b) rbash - restricted shell
> c) SSH2 chroot access.
>
> In this case the machine in question is a remote virtual server with
> only SSH access. So I think c) may be the go.
>
> If I had local users I guess a) or b) with a) having
I. Forbes wrote:
Our rbash shells don't have access to vi ... or much else! Their path
is set to "/usr/local/lib/rbash-bin/" and that directory has sym-links to
a few selected binaries.
BTW
TAB completition works on all directories, so you can discover all files in
systems (in readable director
Hi,
> Our rbash shells don't have access to vi ... or much else! Their
> path is set to "/usr/local/lib/rbash-bin/" and that directory has
> sym-links to a few selected binaries.
>
> Still I don't regard the rbash setup as secure.
Yes but is sound OK for your needs.
In this case I need, or wan
Hello Rudi
On 21 Oct 2003 at 22:58, Rudi Starcevic wrote:
> Though I'd post something I found on the net about rbash.
> I haven't tested it yet.
>
> [quote]
>
> But it's possible to get out from this chroot.
>
> woockie_at_twoflower:~$ cd ..
> rbash: cd: restricted
> woockie_at_twoflower:~$ v
> To sumerize the options I've found so far:
>
> a) PAM chroot
> b) rbash - restricted shell
> c) SSH2 chroot access.
>
> In this case the machine in question is a remote virtual server with
> only SSH access. So I think c) may be the go.
>
> If I had local users I guess a) or b) with a) having
I. Forbes wrote:
Our rbash shells don't have access to vi ... or much else! Their path
is set to "/usr/local/lib/rbash-bin/" and that directory has sym-links to
a few selected binaries.
BTW
TAB completition works on all directories, so you can discover all files in
systems (in readable directo
Hi,
Though I'd post something I found on the net about rbash.
I haven't tested it yet.
[quote]
But it's possible to get out from this chroot.
woockie_at_twoflower:~$ cd ..
rbash: cd: restricted
woockie_at_twoflower:~$ vi foo
in vi:
:set shell=/bin/sh
:shell
woockie_at_twoflower:~$ cd ..
woocki
Hi,
> Our rbash shells don't have access to vi ... or much else! Their
> path is set to "/usr/local/lib/rbash-bin/" and that directory has
> sym-links to a few selected binaries.
>
> Still I don't regard the rbash setup as secure.
Yes but is sound OK for your needs.
In this case I need, or wan
Hello Rudi
On 21 Oct 2003 at 22:58, Rudi Starcevic wrote:
> Though I'd post something I found on the net about rbash.
> I haven't tested it yet.
>
> [quote]
>
> But it's possible to get out from this chroot.
>
> woockie_at_twoflower:~$ cd ..
> rbash: cd: restricted
> woockie_at_twoflower:~$ v
Hi Ian,
> We have a set-up that uses "rbash". The client gets "rbash" as a
> login shell and his path is preset to a directory that has a few
> chosen executables in it.
Most interesting.
Sounds like it would do just what I want.
I'm on to it.
> I suspect a determined hacker could get around t
Hi,
Though I'd post something I found on the net about rbash.
I haven't tested it yet.
[quote]
But it's possible to get out from this chroot.
woockie_at_twoflower:~$ cd ..
rbash: cd: restricted
woockie_at_twoflower:~$ vi foo
in vi:
:set shell=/bin/sh
:shell
woockie_at_twoflower:~$ cd ..
woocki
Hello Rudi
On 18 Oct 2003 at 11:23, Rudi Starcevic wrote:
> Is there anyway to resistict a non-root user's shell account ?
>
> For example once he/she is logged in is there any way to deny, say,
> reading the /etc/passwd file ?
We have a set-up that uses "rbash". The client gets "rbash" as a
Hi Ian,
> We have a set-up that uses "rbash". The client gets "rbash" as a
> login shell and his path is preset to a directory that has a few
> chosen executables in it.
Most interesting.
Sounds like it would do just what I want.
I'm on to it.
> I suspect a determined hacker could get around t
Hello Rudi
On 18 Oct 2003 at 11:23, Rudi Starcevic wrote:
> Is there anyway to resistict a non-root user's shell account ?
>
> For example once he/she is logged in is there any way to deny, say,
> reading the /etc/passwd file ?
We have a set-up that uses "rbash". The client gets "rbash" as a
Marc,
Thanks.
http://www.grsecurity.net looks very interesting.
Another couple of jobs have popped up which I need to address first
so I don't tihink I'll be working on this 'til later in the week.
When I do I'll be sure to post an update to the list.
Many thanks to you all.
It would not be possibl
Marc,
Thanks.
http://www.grsecurity.net looks very interesting.
Another couple of jobs have popped up which I need to address first
so I don't tihink I'll be working on this 'til later in the week.
When I do I'll be sure to post an update to the list.
Many thanks to you all.
It would not be pos
* Rudi Starcevic schrieb am 19.10.03 um 04:30 Uhr:
> Thanks Marc,
>
> Thanks also to Russel.
>
> > I did it with pam_chroot which is really nice
>
> Great - I'll start looking here.
>
> Currently we only really offer FTP access but would like
> to include SSH access too.
>
> I know with the ri
Hi Jason,
Let us all know if this works for you, as I (and I think quite a few ppl
that run ISPs) would be interested to know if this actually works or not
For sure.
Will be spending more time on this latter today and will report my
success/failures/questions.
Cheers
Rudi.
--
To UNSUBSCRIBE, e
19 October, 2003 1:54 PM
Subject: Re: SSH access restrictions
> Thanks Jason,
>
> > Usually you can't... as they have dependency problems.
>
> Well I think it may be OK to just use the 'testing' .deb.
> Why ?
> Because I just did.
> It all installed OK w
Thanks Jason,
> Usually you can't... as they have dependency problems.
Well I think it may be OK to just use the 'testing' .deb.
Why ?
Because I just did.
It all installed OK without any error's.
I just downloaded it and dpkg -i it.
I haven't used it yet as I'm still reading the readme
but it ha
> Hi,
>
> Just a quick question on libpam-chroot.
>
> This package is not availalbe in 'stable'.
> I've only ever used 'stable'.
>
> It should be OK to grab this package from 'testing' and use it hey ?
Usually you can't... as they have dependency problems. What you need is a
"backport" to stabl
Hi,
Just a quick question on libpam-chroot.
This package is not availalbe in 'stable'.
I've only ever used 'stable'.
It should be OK to grab this package from 'testing' and use it hey ?
Thanks again
Regards Rudi.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
Thanks Marc,
Thanks also to Russel.
> I did it with pam_chroot which is really nice
Great - I'll start looking here.
Currently we only really offer FTP access but would like
to include SSH access too.
I know with the right permissions a user account cannot do
any damage but I would just like t
* Rudi Starcevic schrieb am 18.10.03 um 03:23 Uhr:
> Hi,
>
> Is there anyway to resistict a non-root user's shell account ?
>
> For example once he/she is logged in is there any way to deny, say,
> reading the /etc/passwd file ?
> Can they be restricted like the way a user can be restricted usi
On Sat, 18 Oct 2003 11:23, Rudi Starcevic wrote:
> For example once he/she is logged in is there any way to deny, say,
> reading the /etc/passwd file ?
> Can they be restricted like the way a user can be restricted using FTP ?
I have heard of people setting up chroot environments for ssh accounts
29 matches
Mail list logo
