[116] in linux-security and linux-alert archive
Re: Secure setup for file transfer
daemon@ATHENA.MIT.EDU (Elias Levy)
Sun Mar 12 02:14:21 1995
Date: Sat, 11 Mar 1995 20:35:19 -0800 (PST)
From: Elias Levy <elias@power.net>
To: Rik Faith <faith@cs.unc.edu>
cc: linux-security@tarsier.cv.nrao.edu, faith@cs.unc.edu
In-Reply-To: <199503100244.VAA22806@proteus.cs.unc.edu>
Reply-To: linux-security@tarsier.cv.nrao.edu
On Thu, 9 Mar 1995, Rik Faith wrote:
> Can you explain this? X must run as root to get access to the underlying
> hardware (e.g., via the iopl(2) or ioperm(2) calls). Are you using a
> suid'd wrapper to check for a console login in order to get X running as
> root without using the setuid bit on the X binary itself? This seems like
> a bit of overprotectivity to me. If I'm logged in at the console (not
> running X), and someone starts X, I can just switch VC's.
>
Sure. Like you said i run a small wrapper that checks that the user is in
group xwin and then runs the X server. Well yes with X you can simply
chage VC's, but with something like SuperProbe your display can go
into a mess you will not be able to fix unless you reboot. What I would
like to see is these systems call check the uid of the process and allow
access to these io areas if some file in /etc or something passed with lilo
at boot would allow it. These ways systems like X where the drivers are in
user space would not have to be suid root.
> Just a note on tty security in general. I haven't had my tty "screwed up"
> by someone in over 10 years -- and I really don't see this issue as a big
> security risk. In general, it is very hard to prevent denial of service
> attacks under unix, especially when any user can use up all the available
> memory or many of the process slots on the machine. Maybe people are
> seeing these sorts of attacks in undergraduate computing environments or
> some other special situations? Maybe sysadmins in those situations should
> implement better social controls and disciplinary actions. I know that if
> someone in our academic computing environment tried this juvenile tty crap,
> they'd hear from several sysadmins, a few professors, and a bunch of
> students: this type of antisocial behavior would simply not be tolerated.
>
Have your tty screwed is not a nice thing. And just because the are many
other ways to create denial of service attacks does not mean we have to
do nothing about it. Your tty can be screwed from remote. So it does
not have to be an undergraduate computing evironment. We al heard of flash
(talkd) and I can simply send you a mail message that will screw your tty
the moment you load pine, elm, etc.
> I'm mostly concerned with attacks that will allow an ordinary user to
> become root; or that will allow a non-user to gain access to my system or
> its files (e.g., network attacks).
>
elias@power.net (Elias Levy)
PowerNet, Inc.
