David Dyer-Bennet wrote:
>
> Russ Allbery <[EMAIL PROTECTED]> writes on 8 September 1999 at 16:13:46 -0700
> > Ken Jones <[EMAIL PROTECTED]> writes:
blah blah.
If you want a secure system follow these rules:
1) Only grant shell access to trusted users.
2) Physical security
3) Shut off un-ne
> >What prevents me to upload binaries into my home
> >directory/subdirectories, like ~/Maildir/tmp? (Other than carefully
> >controlled ftp access?)
>
>
> Some OSes support mount -noexec which means the OS will not run an
> executable from that mount point. /home, /var and /tmp all are good
>
Russ Allbery <[EMAIL PROTECTED]> writes on 8 September 1999 at 16:13:46 -0700
> Ken Jones <[EMAIL PROTECTED]> writes:
>
> > The best solution i've seen is to group all the programs that are
> > possible security holes, like in.telnet and compilers, to a new
> > group. And only allow members
Ken Jones <[EMAIL PROTECTED]> writes:
> The best solution i've seen is to group all the programs that are
> possible security holes, like in.telnet and compilers, to a new
> group. And only allow members of that group to execute the programs.
If you go that direction, you don't want to do it tha
>On 9 Aug 99, at 10:38, Ken Jones wrote:
> > The best solution i've seen is to group all the programs
> > that are possible security holes, like in.telnet and compilers,
> > to a new group. And only allow members of that group to execute
> > the programs.
> >
> > Just like all the suid programs s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9 Aug 99, at 10:38, Ken Jones wrote:
> The best solution i've seen is to group all the programs
> that are possible security holes, like in.telnet and compilers,
> to a new group. And only allow members of that group to execute
> the programs.
>
>
The best solution i've seen is to group all the programs
that are possible security holes, like in.telnet and compilers,
to a new group. And only allow members of that group to execute
the programs.
Just like all the suid programs should be grouped.
It's a pretty standard security lockdown meth
I'm very confused about this. If the user has a shell account,
how can you possible deny them write permission? I mean, it is
possible,
but it sounds a bit counterintuitive to make their home directory
read-only.
Secondly, if they don't have a shell account, how would they be able
to ed
Dmitry Niqiforoff <[EMAIL PROTECTED]> writes on 8 September 1999 at 11:24:45 +0500
> Yesterday I found that any user are able to start any program at
> server with .qmail file. This could be potentially dangerous, AFAIU. As
> an example: I denied TELNET access (disabled the service in inetd.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Sep 99, at 9:55, Vince Vielhaber wrote:
> But can't joeuser rename the .qmail file to .junk and drop in his own
> .qmail file with the right permissions?
If he doesn't own his homedir, he can't (unless he is granted -w-
inside the directory). O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Sep 99, at 15:48, Jos Backus wrote:
> What about Dan's suggestion?
>
> http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/03/msg00918.html
Hmm - interesting - I have always though that homedir owned by
root is a definition of system ac
On Wed, 8 Sep 1999, Jos Backus wrote:
> What about Dan's suggestion?
>
> http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/03/msg00918.html
>
>
But can't joeuser rename the .qmail file to .junk and drop in his own
.qmail file with the right permissions?
Vince.
--
===
On Wed, 8 Sep 1999, Russell Nelson wrote:
> Dmitry Niqiforoff writes:
> > Yesterday I found that any user are able to start any program at
> > server with .qmail file. This could be potentially dangerous, AFAIU.
>
> Only if you let users edit their own .qmail files. Don't. Deny them
> writ
What about Dan's suggestion?
http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/03/msg00918.html
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
_/ _/
Dmitry Niqiforoff writes:
> Yesterday I found that any user are able to start any program at
> server with .qmail file. This could be potentially dangerous, AFAIU.
Only if you let users edit their own .qmail files. Don't. Deny them
write permission in their home directory. If they need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Sep 99, at 11:48, Robert Varga wrote:
> On Wed, 8 Sep 1999, Sebastian Andersson wrote:
>
> > On Wed, Sep 08, 1999 at 11:24:45AM +0500, Dmitry Niqiforoff wrote:
> > > Is there any suggestions about how to avoid all the potential
> > > problems?
On Wed, 8 Sep 1999, Sebastian Andersson wrote:
> On Wed, Sep 08, 1999 at 11:24:45AM +0500, Dmitry Niqiforoff wrote:
> > Is there any suggestions about how to avoid all the potential
> > problems?
What is the problem? They run programs with their uid and gid.
They would not be able to run in.
On Wed, Sep 08, 1999 at 11:24:45AM +0500, Dmitry Niqiforoff wrote:
> Is there any suggestions about how to avoid all the potential
> problems?
Yes.
1) Hack qmail-local to deny | usage for your users (check the gid?).
2) Prevent the users from creating .qmail files. Our users homedirs are
owned
Hello!
Yesterday I found that any user are able to start any program at
server with .qmail file. This could be potentially dangerous, AFAIU. As
an example: I denied TELNET access (disabled the service in inetd.conf),
but any user can put "|in.telnetd" in their .qmail file (ofcourse, there
shoul
19 matches
Mail list logo
