From: "Tom Moore" <tom@tomstroubleshooting.com>
To: "'Speakup is a screen review system for Linux.'"
<speakup@braille.uwo.ca>
Subject: RE: making secure limitations for non-root users
Date: Fri, 19 Sep 2008 17:52:58 -0400 [thread overview]
Message-ID: <EBCC0EF365F5425F9DC59F998D519E46@ZEUS> (raw)
In-Reply-To: <000701c91aa0$4fcdd9b0$4200a8c0@tdsportable>
By default users can not read files in /var/log so you don't have to worry
about that.
If your running a system and don't trust the users who you are allowing on
to the system not to do anything wrong while you yourself are still learning
how to secure the system up you could be asking for real trouble.
Remember as a residential user and this may to apply to business users as
well you are responsible for anything that goes in to or out of your
internet connection, and if you don't trust who is actively using it at the
end of the day it could be your head on the chopping block when it comes to
issues with your isp.
Tom
-----Original Message-----
From: speakup-bounces@braille.uwo.ca [mailto:speakup-bounces@braille.uwo.ca]
On Behalf Of Tyler Littlefield
Sent: Friday, September 19, 2008 5:40 PM
To: Speakup is a screen review system for Linux.
Subject: Re: making secure limitations for non-root users
I'll dig around for that kernel patch.
Like, limiting them to viewing home dirs, other people's dirs. I can do
chmod a-r /home, and then chmod o-rx /home/user, but would there be anything
else I'd need to limit for security reasons? I'd not like to scrue up perms
on logs, but would rather not them see /var/log.
Thanks,
_|_|_|_|_| _| _|_|_|_|
_| _|_|_| _| _|_|_|
_| _| _| _|_|_| _|
_| _| _| _| _|
_| _| _| _|_|_|_| _|_|_|
Visit TDS for quality software and website production
http://tysdomain.com
msn: tyler@tysdomain.com
aim: st8amnd2005
skype: st8amnd127
----- Original Message -----
From: "Gregory Nowak" <greg@romuald.net.eu.org>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Sent: Friday, September 19, 2008 3:38 PM
Subject: Re: making secure limitations for non-root users
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tom has already told you what the best approach would be. However, let
> me try to specifically answer your questions.
>
> On Thu, Sep 18, 2008 at 12:39:40PM -0600, Tyler Littlefield wrote:
>> I would, however like to limit them in disk space (I can figure that
> one out),
>
> Ok.
>
>> in port usage (not sure how to do this one, would like to limit what
> ports they can open),
>
> The only thing I can think of for that is the obvious, a
> firewall. However, that would apply to everyone on the system. There
> is something called owner match support, when you're configuring the
> firewall stuff in the kernel, however, I'm not sure if that does what
> it actually suggests, or something else. Sorry, that's all I can tell
> you there, maybe a firewall howto somewhere would tell you more.
>
>> programs they can run,
>
> The best way I can think of to do that, is to create a group on your
> system, where all the binaries you want users to access are a part of
> that group. Then, add the users you want to be able to access those
> binaries to that group as well, and leave the rest binaries/users
> out. On my debian system, there is a group called bin, but most of my
> binaries are in root's group. I'm not sure if the bin group is
> reserved for something else, or if it is there for what its name
> suggests, and it's up to the system admin to use it as he/she wishes.
>
>> and also what they can view on the system.
>
> You need to be more specific. What do you want them to be able to
> view, man pages, text files, contents of specific directories, what?
>
> Greg
>
>
> - --
> web site: http://www.romuald.net.eu.org
> gpg public key: http://www.romuald.net.eu.org/pubkey.asc
> skype: gregn1
> (authorization required, add me to your contacts list first)
>
> - --
> Free domains: http://www.eu.org/ or mail dns-manager@EU.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkjUG8gACgkQ7s9z/XlyUyDY8QCeMyiUbYUWG+XeixZqmeq2vnxW
> zckAoLvhv/znPYpTPB1hr6BxFVZl81/r
> =+v8G
> -----END PGP SIGNATURE-----
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> __________ NOD32 3457 (20080919) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup
next prev parent reply other threads:[~ UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
Tyler Littlefield
` Tom Moore
` Tyler Littlefield
` Gregory Nowak
` Tyler Littlefield
` Tom Moore [this message]
` Jim Kutsch
` Tyler Littlefield
` Tony Baechler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EBCC0EF365F5425F9DC59F998D519E46@ZEUS \
--to=tom@tomstroubleshooting.com \
--cc=speakup@braille.uwo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).