On Wednesday 10 November 2004 21:49, "Ben Hutchings"
<[EMAIL PROTECTED]> wrote:
> > I feel the need to learn something new today. How could the user replace
> > the root owned files in a directory that they own?
>
> By renaming or unlinking them. Linux treats this as an operation on the
> directo
On Sat, 20 Nov 2004 07:36:05 -0700, Wesley J Landaker <[EMAIL PROTECTED]> wrote:
> On Sunday, 07 November 2004 18:14, [EMAIL PROTECTED] wrote:
> > You just need to add group(access) to that system accounts that you
> > want or that you think that they'll break in unexpected places...
> > Don't you
On Sunday, 07 November 2004 18:14, [EMAIL PROTECTED] wrote:
> You just need to add group(access) to that system accounts that you
> want or that you think that they'll break in unexpected places...
> Don't you think?
Why not do this the other way around; it's much simpler:
e.g. add users you don'
Michael Graham wrote:
/tmp/test$ ll
total 0
-rw-r--r-- 1 root root 0 2004-11-15 00:36 test
/tmp/test$ ll -d ../test/
drwxr-xr-t 2 mick mick 4.0K 2004-11-15 00:36 ../test/
/tmp/test$ rm test
rm: remove write-protected regular empty file `test'? y
/tmp/test$ ll
total 0
But according to the man page
On Tue, 09 Nov 2004 20:58:33 +0100, Dan Roozemond wrote:
> Suppose the root-owned file (readable for non-root user) is a. Then one does
> 'cp a b; rm a; mv b a' and we have the same file a owned by the regular
> user. Key observation here is that the non-root user ownes the directory,
> hence can r
Michael Graham wrote:
Ben Hutchings wrote:
Christopher Swingley wrote:
Change the ownership and permissions on their .bash_profile and .bashrc
to root:root 644:
-rw-r--r--1 root root 420 Sep 21 13:05
.bash_profile -rw-r--r--1 root root 746 Sep 21
13:05 .ba
On Tue, 09 Nov 2004 17:43:19 -0500, Doug Griswold <[EMAIL PROTECTED]> wrote:
> can upload the changes. You will get tired of that real quick. Other
> than this method there is always a what if factor selinux,chroot,
> virtual server etc...
The point is to minimize the "what if" factors by choos
Don't give them shell access, and don't let them ftp to the server.
Make them email you all the changes so you can browse for bad code.
Then you
can upload the changes. You will get tired of that real quick. Other
than this method there is always a what if factor selinux,chroot,
virtual serve
On Mon, 8 Nov 2004 09:28:10 -0900, Christopher Swingley
<[EMAIL PROTECTED]> wrote:
> Make symbolic links between allowed commands and '/usr/local/rbin'
>
> As I said before, this is just a simple attempt to reduce priviledge.
> There are undoubtably ways around it, some easier than others dependin
On Tue, Nov 09, 2004 at 07:15:01PM +, Michael Graham wrote:
> Ben Hutchings wrote:
> > Christopher Swingley wrote:
> >> Change the ownership and permissions on their .bash_profile and .bashrc
> >> to root:root 644:
> >>
> >> -rw-r--r--1 root root 420 Sep 21 13:05
> >>
> I feel the need to learn something new today. How could the
> user replace
> the root owned files in a directory that they own?
>
Suppose the root-owned file (readable for non-root user) is a. Then one does
'cp a b; rm a; mv b a' and we have the same file a owned by the regular
user. Key obser
Ben Hutchings wrote:
> Christopher Swingley wrote:
>> Change the ownership and permissions on their .bash_profile and .bashrc
>> to root:root 644:
>>
>> -rw-r--r--1 root root 420 Sep 21 13:05
>> .bash_profile -rw-r--r--1 root root 746 Sep 21
>> 13:05 .
Christopher Swingley wrote:
This is what I've done when I wanted to reduce the set of commands a
user could run. I'm sure a reasonably competant Unix user could easily
circumvent these restrictions, but it's a good first start, and making
such attempts would result in account suspension.
Chan
Greetings,
* Osamu Aoki <[EMAIL PROTECTED]> [2004-Nov-05 14:13 AKST]:
> On Fri, Nov 05, 2004 at 09:31:21AM -0800, Stephen Le wrote:
> > Is there an easy way to limit the commands a certain group of users
> > can execute?
>
> I never done this but..
>
> Use of chroot with bash started as rbash se
On Mon, Nov 08, 2004 at 03:14:53AM +0200, [EMAIL PROTECTED] wrote:
> > On Fri, Nov 05, 2004 at 07:53:33PM +0200, [EMAIL PROTECTED] wrote:
> >> >In regards to the latter method, would it be possible for me to change
> >> >the group ownership of the commands I don't want users to have access
> >> to
> On Fri, Nov 05, 2004 at 07:53:33PM +0200, [EMAIL PROTECTED] wrote:
>> >In regards to the latter method, would it be possible for me to change
>> >the group ownership of the commands I don't want users to have access
>> to
>> >and revoke execute permission from that group?
>>
>> Yes, you can make
I wrote:
> No need for C. Perl suffices.
Stephen Le writes:
> I should be able to restrict a user's Perl scripts using Apache's
> suEXEC. I don't see how a user would be able to remotely execute a
> compiled C program outside of their priviledges.
I meant that they can do anything with Perl that
On Sun, 2004-11-07 at 14:54, Stephen Le wrote:
>
> > Note that neither my approach nor yours really stops someone who is
> > determined - all of the functionality of the above programs could be
> > replicated in perl, python, etc, so you've only made it difficult, not
> > impossible. Then there
On Sun, 7 Nov 2004 14:41:42 -0500, Stephen Gran <[EMAIL PROTECTED]> wrote:
> apt-get remove --purge ftp telnet wget gcc
> rm /usr/bin/ssh /usr/bin/scp
Unfortunately, I can't do that since I still want some users to be
able to access those commands. I just want to restrict access to those
commands
This one time, at band camp, Stephen Le said:
> On Sun, 7 Nov 2004 14:14:16 +, Steve Kemp <[EMAIL PROTECTED]> wrote:
> > Lots of people have commented already, but I've not seen any
> > discussion on why you might want to do this. What kind of bad
> > commands are you trying to prevent?
>
> For example, as I mentioned in an earlier reply, I might not want
> normal users to be able to run ftp, telnet, ssh, wget, gcc, or any
> other number of commands. I still want users to be able to run the
> bulk of the commands available on the system, though. I might also
> want to allow another
On Sun, 07 Nov 2004 10:10:31 -0600, John Hasler <[EMAIL PROTECTED]> wrote:
> Steve Kemp writes:
> > If you give people the ability to upload CGI scripts, like the perl
> > example you mention, you've already lost - a malicious user could compile
> > some C code statically and exectute that remotely
On Sun, 7 Nov 2004 14:14:16 +, Steve Kemp <[EMAIL PROTECTED]> wrote:
> Lots of people have commented already, but I've not seen any
> discussion on why you might want to do this. What kind of bad
> commands are you trying to prevent?
>
> Most of the dangerous commands like fdisk, etc, w
Steve Kemp writes:
> If you give people the ability to upload CGI scripts, like the perl
> example you mention, you've already lost - a malicious user could compile
> some C code statically and exectute that remotely.
No need for C. Perl suffices.
--
John Hasler
--
To UNSUBSCRIBE, email to [E
On Fri, Nov 05, 2004 at 03:35:11PM -0800, Stephen Le wrote:
> See the example above. Users would still be able to upload their own
> Perl scripts and get Apache to execute them without restriction - the
> Perl script could call commands that I want to ban the users from
> executing.
Lots of peo
also sprach Steve Kemp <[EMAIL PROTECTED]> [2004.11.07.1514 +0100]:
> If you're operating a shared system and want to keep seperate
> web users isolated from each other using rbash, chroots or
> similar should be sufficient.
Neither rbash not chroots are security measures. They are hurdles at
On Fri, Nov 05, 2004 at 07:53:33PM +0200, [EMAIL PROTECTED] wrote:
> >In regards to the latter method, would it be possible for me to change
> >the group ownership of the commands I don't want users to have access to
> >and revoke execute permission from that group?
>
> Yes, you can make somethin
> On Fri, 5 Nov 2004 19:53:33 +0200 (EET), [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Yes, you can make something like that: addgroup(access), then change
>> groupname of commands that you want with that group (access), remember
>> to
>> remove "execute/search by others" from commands that a
On Sat, Nov 06, 2004 at 11:21:43AM -0800, Stephen Le wrote:
> On Sat, 6 Nov 2004 12:43:27 -0500, Kevin Mark
> <[EMAIL PROTECTED]> wrote:
> > I think it is worth the extra 'sudo'. People should learn the difference
> > between regular commands and special commands. you can have sudo ask for
> > a pa
On Sat, 6 Nov 2004 16:55:33 +0100, Lukas Ruf <[EMAIL PROTECTED]> wrote:
> > If they got Apache to execute the script, the "bad_command" would be
> > run. This is the reason why I'm trying to approach this problem from
> > a permissions standpoint. Of course, someone might suggest running
> > an Apa
On Sat, 6 Nov 2004 12:43:27 -0500, Kevin Mark
<[EMAIL PROTECTED]> wrote:
> I think it is worth the extra 'sudo'. People should learn the difference
> between regular commands and special commands. you can have sudo ask for
> a password or not. Ubuntu uses a sudo-like thing. Users should be asked
>
On Fri, Nov 05, 2004 at 01:19:53PM -0800, Stephen Le wrote:
> On Fri, 5 Nov 2004 18:40:59 +0100, Benedict Verheyen
> <[EMAIL PROTECTED]> wrote:
> > Sounds like you want sudo.
>
> I don't think sudo is appropriate for what I'm trying to do. I'd like
> users to have limited shell access; I'm not try
> Stephen Le <[EMAIL PROTECTED]> [2004-11-06 00:36]:
>
> On Sat, 6 Nov 2004 00:13:28 +0100, Osamu Aoki <[EMAIL PROTECTED]>
> wrote:
> > > Is there an easy way to limit the commands a certain group of
> > > users can execute? I've looked at chroot, and it's too
> > > complicated for my needs and see
On 06.11.2004 00:35 Stephen Le wrote:
Is there an easy way to limit the commands a certain group of users
can execute?
Indeed. A chroot would only apply to a user if they were logged into
the system. Let's say I wanted to prevent users executing the command
"bad_command". Well, if "bad_command" wa
On Sat, 6 Nov 2004 00:13:28 +0100, Osamu Aoki <[EMAIL PROTECTED]> wrote:
> > Is there an easy way to limit the commands a certain group of users
> > can execute? I've looked at chroot, and it's too complicated for my
> > needs and seems too easy to circumvent; users will be able to upload
> > their
On Fri, Nov 05, 2004 at 09:31:21AM -0800, Stephen Le wrote:
> Hello all,
>
> Is there an easy way to limit the commands a certain group of users
> can execute? I've looked at chroot, and it's too complicated for my
> needs and seems too easy to circumvent; users will be able to upload
> their own
On Fri, 5 Nov 2004 18:40:59 +0100, Benedict Verheyen
<[EMAIL PROTECTED]> wrote:
> Sounds like you want sudo.
I don't think sudo is appropriate for what I'm trying to do. I'd like
users to have limited shell access; I'm not trying to give them access
to special commands. Besides, telling users to p
On Fri, 5 Nov 2004 19:53:33 +0200 (EET), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Yes, you can make something like that: addgroup(access), then change
> groupname of commands that you want with that group (access), remember to
> remove "execute/search by others" from commands that are with
>
Take a look at sudo.
>>> Stephen Le <[EMAIL PROTECTED]> 11/5/2004 12:31:21 PM >>>
Hello all,
Is there an easy way to limit the commands a certain group of users
can execute? I've looked at chroot, and it's too complicated for my
needs and seems too easy to circumvent; users will be able to upload
> Hello all,
>
> Is there an easy way to limit the commands a certain group of users
> can execute? I've looked at chroot, and it's too complicated for my
> needs and seems too easy to circumvent; users will be able to upload
> their own Perl scripts, so it seems that they'll be able to access
> co
>-Oorspronkelijk bericht-
>Van: Stephen Le [mailto:[EMAIL PROTECTED]
>Verzonden: vrijdag 5 november 2004 18:31
>Aan: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Onderwerp: Limiting User Commands
>
>
>Hello all,
>
>Is there an easy way to limit the commands a certa
Hello all,
Is there an easy way to limit the commands a certain group of users
can execute? I've looked at chroot, and it's too complicated for my
needs and seems too easy to circumvent; users will be able to upload
their own Perl scripts, so it seems that they'll be able to access
commands outsid
42 matches
Mail list logo
