Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-25 12:08:12 +0200, Andrei POPESCU wrote:
> Alt-SysRq-F is disabled on sid:
> mar 25 12:03:28 sid kernel: SysRq : This sysrq operation is disabled.

But what if someone logs in, uses all the memory left (possibly not
even in a malicious way) so that this triggers the OOM killer, and
the OOM killer chooses the screen saver as the application to kill?

The right thing is that the screen saver should protect itself
against the OOM killer.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140325130315.ga26...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Vi, 21 mar 14, 10:34:03, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > > 
> > > You can access the console X was started from even when the machine is
> > > locked.
> > 
> > Seriously? I'd find that to be a severe bug in the said locking 
> > application.

I have to correct myself here, apparently the application tries to do 
everything right, but...
http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs

> It's a feature of linux being multi-user. You come up to a machine
> that's running Xscreensaver (et al.) change to another VT, login there
> and start another X server. GDM can facilitate this with the Switch User
> functionality, but it's perfectly normal behaviour even without.
> 
> If you don't want people terminating your X session from the console, I
> think the best solution is to use a display manager, which re-uses the
> VT, and to turn on DontZap.

With a display manager one doesn't need DontZap and DontVTSwitch, as 
long as one is not logged in on one of the consoles.

Alt-SysRq-F is disabled on sid:
mar 25 12:03:28 sid kernel: SysRq : This sysrq operation is disabled.

AllowClosedownGrabs doesn't exist in xorg.conf(5) and 
Ctrl-Alt-KP_Multiply doesn't do anything on sid.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Mon 24 Mar 2014 at 12:37:36 +0100, Vincent Lefevre wrote:

> On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> > Seems I'm a little bit old-fashioned ;-)
> > According to the man-page Xsession(5) the system scripts take care of using 
> > a
> > log-file, given that you indeed don't have ~/.xinitrc .
> > So maybe the man-page of startx(1) has to be updated, since it only talks 
> > about
> > ~/.xinitrc .
> 
> Because startx runs the xinitrc (either the user's one or the system
> one) and doesn't know anything about the .xsession file. Xsession files
> (including the user's .xsession) are sourced via the system xinitrc.
> Perhaps a section about Debian recommendations and default configuration
> should be added.

There was a time when startx(1) contained the advice:

  Note that in the Debian system, what many people traditionally put in
  the .xinitrc file should go in .xsession instead; this permits the same
  X environment to be presented whether startx, xdm, or xinit is used to
  start the X session. All discussion of the .xinitrc file in the
  xinit(1) manual page applies equally well to .xsession. Keep in mind
  that .xinitrc is used only by xinit(1) and completely ignored by
  xdm(1).

It is interesting that there is not a single reference to .xinitrc in
Chapter 7 of the Debian Reference.

The only use I can think of off-hand for a .xinitrc is to avoid using
the Debian-specific Xsession if the system administrator has commented
out "allow-user-resources" in /etc/X11/Xsession.options.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140324124539.gl4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> Seems I'm a little bit old-fashioned ;-)
> According to the man-page Xsession(5) the system scripts take care of using a
> log-file, given that you indeed don't have ~/.xinitrc .
> So maybe the man-page of startx(1) has to be updated, since it only talks 
> about
> ~/.xinitrc .

Because startx runs the xinitrc (either the user's one or the system
one) and doesn't know anything about the .xsession file. Xsession files
(including the user's .xsession) are sourced via the system xinitrc.
Perhaps a section about Debian recommendations and default configuration
should be added.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140324113736.ga22...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

Seems I'm a little bit old-fashioned ;-)
According to the man-page Xsession(5) the system scripts take care of using a
log-file, given that you indeed don't have ~/.xinitrc .
So maybe the man-page of startx(1) has to be updated, since it only talks about
~/.xinitrc .

Best regards,
Jörg-Volker.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgnesg$pl5$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 21:19:59 +0100, Sven Joachim wrote:

> On 2014-03-22 20:14 +0100, Brian wrote:
> 
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account.
> 
> Care to elaborate why not?  If they use startx, I think they want an
> ~/.xinitrc.

>From /usr/bin/startx:

  # This is just a sample implementation of a slightly less primitive
  # interface than xinit.  It looks for user .xinitrc and .xserverrc
  # files, then system xinitrc and xserverrc files, else lets xinit choose
  # its default.  The system xinitrc should probably do things like check
  # for .Xresources files and merge them in, start up a window manager,
  # and pop a clock and several xterms.

If .xinitrc is found it is used. The system xinitrc in /etc/X11/xinit/
is not consulted. This means that none of Debian's carefully crafted
configuration files in /etc/X11 are sourced.

> > A happy Debian system is one with ~/.xsession.
> 
> I have symlinked ~/.xsession to .xinitrc, but there may be reasons for
> having different content in these files.

The consequence of a symlink is described above. With two separate files
.xsession is not used.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140323000356.gj4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 15:02:58 -0500, Bill Wood wrote:

> On Sat, 2014-03-22 at 19:14 +, Brian wrote:
>. . .
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account. A happy Debian system is one with ~/.xsession.
> 
> I'm a Debian newbie, so -- why?

We had a fairly full discussion on startx, .xinitrc and .xsession in
debian-user in December of last year. The Mailing List Archives for that
month have a record of it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014032343.gi4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Sven Joachim]

On 2014-03-22 20:14 +0100, Brian wrote:

> On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:
>
>> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
>> > In order to keep the output of the X-session when starting with the command
>> > startx, something like the following snippet could be inserted into the 
>> > file
>> > ~/.xinitrc :
>
> This is the fourth or fifth time in this thread a recommendation to use
> ~/.xinitrc has been made. No sensible Debian user would have such a file
> in his account.

Care to elaborate why not?  If they use startx, I think they want an
~/.xinitrc.

> A happy Debian system is one with ~/.xsession.

I have symlinked ~/.xsession to .xinitrc, but there may be reasons for
having different content in these files.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87siqax9xs@turtle.gmx.de

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Bill Wood]

On Sat, 2014-03-22 at 19:14 +, Brian wrote:
   . . .
> This is the fourth or fifth time in this thread a recommendation to use
> ~/.xinitrc has been made. No sensible Debian user would have such a file
> in his account. A happy Debian system is one with ~/.xsession.

I'm a Debian newbie, so -- why?

-- 
Bill Wood


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1395518578.7408.1.camel@bills-debian

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:

> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> > In order to keep the output of the X-session when starting with the command
> > startx, something like the following snippet could be inserted into the file
> > ~/.xinitrc :

This is the fourth or fifth time in this thread a recommendation to use
~/.xinitrc has been made. No sensible Debian user would have such a file
in his account. A happy Debian system is one with ~/.xsession.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322191413.gh4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> In order to keep the output of the X-session when starting with the command
> startx, something like the following snippet could be inserted into the file
> ~/.xinitrc :
> 
> 
> sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"
> 
> # Send output to file
> #
> logfile="${XDG_CACHE_HOME:-$HOME}/xinit-${sessid}.log"
> : > "$logfile"
> chmod go-rwx "$logfile"
> exec > "$logfile" 2>&1
> unset logfile
> 
> 
> If the environment variable XDG_CACHE_HOME is set, the output from X is 
> written
> to, e.g., "${XDG_CACHE_HOME}/xinit-0.log" otherwise to "~/init-0.log".

Sorry, should read

to, e.g., "${XDG_CACHE_HOME}/xinit-debian-0.log" otherwise to
"~/xinit-debian-0.log" on a computer named "debian".

> 
> Regards,
> Jörg-Volker.
> 
> 
> 



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgkevk$jbs$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jörg-Volker Peetz]

In order to keep the output of the X-session when starting with the command
startx, something like the following snippet could be inserted into the file
~/.xinitrc :


sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"

# Send output to file
#
logfile="${XDG_CACHE_HOME:-$HOME}/xinit-${sessid}.log"
: > "$logfile"
chmod go-rwx "$logfile"
exec > "$logfile" 2>&1
unset logfile


If the environment variable XDG_CACHE_HOME is set, the output from X is written
to, e.g., "${XDG_CACHE_HOME}/xinit-0.log" otherwise to "~/init-0.log".

Regards,
Jörg-Volker.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgkbjk$gdn$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Joel Rees]

On Sat, Mar 22, 2014 at 8:51 AM, Brian  wrote:

> On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com
> wrote:
>
> > I think it depends on the situation. If you're at the library with your
> > laptop and need to go to the bathroom, it's best to take the computer
> > with you, because it's easier to just walk off with it than to dink
> > with the command prompt. I have my office in my home, where I trust
> > everyone who goes in my office, so startx is fine.
>
> This has just struck me. I wish it hadn't but Friday nights bring on
> strange thoughts:
>
> I have a picture in my mind of you and your colleagues standing in the
> bathroom and admiring each others bezels.
>

Hmm. Home office. Colleague?

Hmmm, yeah. Nothing wrong with admiring that particular colleague's
bezel, I think.

>;->

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 13:35:37 -0400, Steve Litt of Troubleshooters.Com wrote:
> To cure my paranoia of having stdout going to an unknown place, I made
> the following executable /usr/local/bin/exx:
> 
> ==
> #!/bin/bash
> startx > /dev/null & exit
> ==
> 
> I invoke it like this:
> 
> . exx
> 
> I think that dot space before the command is similar to "exec", which
> runs it in the current process, so the current process, rather than a
> spawned process, is what gets exited. It appears to work perfectly,
> logging out tty1 the instant X is up and running.
> 
> I didn't plan this, but this 2 line shellscript has the added benefit
> that if I forget the dot, and forgetting it would leave the bash
> session open, it tells me I don't have privileges to run X, and refuses
> to run X. So I can't make a dumb mistake.

It might be a bug and the behavior might change in the future.

To really make sure that X won't run if you forget the dot:

#!/bin/false
startx > /dev/null & exit

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322115959.gb25...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 17:13:41 +0100, Gian Uberto Lauri wrote:
> Vincent Lefevre writes:
>  > The fact that it is multi-user doesn't mean that it will necessarily
>  > be used by several desktop users.
> 
> You can remove spawning the getty on tty you don't want to use.
> 
> I don't know how to do this with systemd... With init you had some
> nice and well commented entries in /etc/inittab
> 
> The multiple console is a feature dating back when there was no X11
> available for GNU/Linux...

Note that I do *not* want to remove the multiple console feature.
It is useful even when there is a single user.

>  > I suppose that users who use startx haven't installed a display manager.
>  > So, I think that the feature should be enabled only when a display
>  > manager is running.
>  > 
>  > Actually even better: if user A has locked his X session, then
>  > the system should prevent any switch to a Linux console where
>  > A has logged in.
> 
> This would be nice, but I think is sort of an hell... 
> 
> When the user presses the magic sequence, the one in charge of
> switching tty should pick the process table, identify X and a possible
> screen saver (how? I could use a custom written screensaver called
> ullabagulla), then identify which the parent process of X and see
> which tty it belongs to, and block any attempt to switch to that tty.

Perhaps the kernel should have a new feature that could be used
for tty switching permissions.

> AFAIK Ctrl+Alt+F1 trows a trap, therefore all the stuff above has
> to run in kernel space...

Yes, except that...

> A safer solution should be to remove all the getty except one. But
> these tty are useful to recover a system in bad times...

Even "remove all the getty except one" is not safe, because the
problem is precisely the tty where the user has logged on and run
startx.

Now, the X-locking process could still remap the keyboard to remove
all these XF86Switch_VT_* from the mappings, so that I suppose that
tty switching would no longer be possible, and restored the settings
at the end. And perhaps it can do this selectively, i.e. only do
this for tty's where the user has logged on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140322111723.ga25...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> with the command prompt. I have my office in my home, where I trust
> everyone who goes in my office, so startx is fine.

This has just struck me. I wish it hadn't but Friday nights bring on
strange thoughts:

I have a picture in my mind of you and your colleagues standing in the
bathroom and admiring each others bezels.

NOTE.
-

For the avoidance of any doubt and as an aid to non-native English
speakers a "bezel" can be the front surround of a monitor screen or
the panel surrounding the slot of a CD drive CD or covering empty
drive bays. It is intended to give the computer a more appealing
look.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321235148.gg4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> with the command prompt. I have my office in my home, where I trust
> everyone who goes in my office, so startx is fine.

Easier? Dinking? Don't be silly.
 
> But if I were working in a cube farm with a desktop, where hundreds of
> people walk by my computer every day, and in fact some might actually
> have business being on my computer, disabling a 5 second route to a
> command prompt logged in as me would be a very good thing.

So you do not have the default tty_tickets setting as "off". Your
account; your responsibility. What's the problem?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321225815.gf4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:

> On Fri, 21 Mar 2014 11:06:03 +
> Robin  wrote:
> 
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root password?
> 
> Unless you have a BIOS password or encrypted root partition (or
> encrypted partition where /etc resides), yes. The OP's point was that
> those things take 5 minutes, whereas killing X started by startx gives
> the guy a logged-in command prompt in about 5 seconds, especially if
> Ctrl+Alt+Backspace is enabled to instantly kill X.

I'm having difficulty seeing any inherent "insecurity" in startx (or in
sudo for that matter) and crediting the OP's two points with any
particular importance.  Firstly, a logged-in command prompt is there
without killing X and secondly you don't need to leave X to kill X.

Giving anyone free run of your account can lead to anything happening
unless you take steps to avoid it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321175408.gd4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 14:25:14 +0100
"Valerio Vanni"  wrote:

> "Brian"  ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
> 
> > For the situation when X is started with startx would 'startx &
> > exit' prevent the termination of an X session even if CTRL+ALT+FN
> > etc gets console access?
> 
> I've always used "startx & exit", and it works perfectly.
> It doesn't prevent the termination of an X session, but if it's
> terminated you get a logon prompt as if you had just booted the
> machine.

I just tried both:

startx & exit

startx; exit

The former logs out of the original bash session immediately, running X
in the background, so you see no stdout from X. I don't know where it
goes.

The latter shows the stdout from X, but when you leave X, whether
normally from Xfce or by Ctrl+C'ing in tty1, it automatically logs out
of the bash session and leaves you at the login prompt.

I guess the choice between these two depends on how valuable you think
it is to see the stdout from X (for debugging, presumably), how worried
you are about where all that stdout is going if X is run in the
background, how worried you are that somebody could find a way of
killing X and simultaneously preventing the exit to happen.

To cure my paranoia of having stdout going to an unknown place, I made
the following executable /usr/local/bin/exx:

==
#!/bin/bash
startx > /dev/null & exit
==

I invoke it like this:

. exx

I think that dot space before the command is similar to "exec", which
runs it in the current process, so the current process, rather than a
spawned process, is what gets exited. It appears to work perfectly,
logging out tty1 the instant X is up and running.

I didn't plan this, but this 2 line shellscript has the added benefit
that if I forget the dot, and forgetting it would leave the bash
session open, it tells me I don't have privileges to run X, and refuses
to run X. So I can't make a dumb mistake.

I'm probably going to start using this exx script on all my Debian
computers.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321133537.5e3e923b@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Steve Litt of Troubleshooters.Com writes:

 > I think it depends on the situation. If you're at the library with your
 > laptop and need to go to the bathroom, it's best to take the computer
 > with you, because it's easier to just walk off with it than to dink
 > with the command prompt.

Easier and  more profitable. Even  when all  the data it  contains are
available on youp...Wikimedia!

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.27806.549348.748...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 11:06:03 +
Robin  wrote:

> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

Unless you have a BIOS password or encrypted root partition (or
encrypted partition where /etc resides), yes. The OP's point was that
those things take 5 minutes, whereas killing X started by startx gives
the guy a logged-in command prompt in about 5 seconds, especially if
Ctrl+Alt+Backspace is enabled to instantly kill X.

I think it depends on the situation. If you're at the library with your
laptop and need to go to the bathroom, it's best to take the computer
with you, because it's easier to just walk off with it than to dink
with the command prompt. I have my office in my home, where I trust
everyone who goes in my office, so startx is fine.

But if I were working in a cube farm with a desktop, where hundreds of
people walk by my computer every day, and in fact some might actually
have business being on my computer, disabling a 5 second route to a
command prompt logged in as me would be a very good thing.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321123757.653c8c4e@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Fri, 21 Mar 2014 09:24:21 +
Jonathan Dowland  wrote:

> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > through 12, respectively. This can be disabled with the
> > DontVTSwitch xorg.conf(5) file  option.
> 
> I doubt that stops e.g. chvt(1) from working. I'm sure there are a
> myriad other ways to switch VT from within the X session, too.

Not only that, but I don't think a day goes by when I don't switch to a
VT to do CLI stuff, or even to kill X because X hung (not so much in
Debian, but in other distros).

I'd rather shut down the computer when I leave to go to the bathroom
than set it up so I couldn't Ctrl+Alt+F3 to get a CLI environment any
time I wanted.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321122649.69d515f7@mydesk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Vincent Lefevre writes:
 > The fact that it is multi-user doesn't mean that it will necessarily
 > be used by several desktop users.

You can remove spawning the getty on tty you don't want to use.

I don't know how to do this with systemd... With init you had some
nice and well commented entries in /etc/inittab

The multiple console is a feature dating back when there was no X11
available for GNU/Linux...

 > I suppose that users who use startx haven't installed a display manager.
 > So, I think that the feature should be enabled only when a display
 > manager is running.
 > 
 > Actually even better: if user A has locked his X session, then
 > the system should prevent any switch to a Linux console where
 > A has logged in.

This would be nice, but I think is sort of an hell... 

When the user presses the magic sequence, the one in charge of
switching tty should pick the process table, identify X and a possible
screen saver (how? I could use a custom written screensaver called
ullabagulla), then identify which the parent process of X and see
which tty it belongs to, and block any attempt to switch to that tty.

AFAIK Ctrl+Alt+F1 trows a trap, therefore all the stuff above has
to run in kernel space...

A safer solution should be to remove all the getty except one. But
these tty are useful to recover a system in bad times...

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.25909.561006.437...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 11:41:29 +, Brian wrote:
> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?

Doing the exit immediately can have some side effects in some
configurations. For instance, my configuration requires at least
one logging shell or X being started via a display manager.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321154957.gb7...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-21 10:34:03 +, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > > 
> > > You can access the console X was started from even when the machine is
> > > locked.
> > 
> > Seriously? I'd find that to be a severe bug in the said locking 
> > application.
> 
> It's a feature of linux being multi-user.

The fact that it is multi-user doesn't mean that it will necessarily
be used by several desktop users.

> You come up to a machine that's running Xscreensaver (et al.) change
> to another VT, login there and start another X server. GDM can
> facilitate this with the Switch User functionality, but it's
> perfectly normal behaviour even without.

I suppose that users who use startx haven't installed a display manager.
So, I think that the feature should be enabled only when a display
manager is running.

Actually even better: if user A has locked his X session, then
the system should prevent any switch to a Linux console where
A has logged in.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321153930.ga7...@ypig.lip.ens-lyon.fr

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 14:25:14 +0100, Valerio Vanni wrote:

> "Brian"  ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
> 
> > For the situation when X is started with startx would 'startx & exit'
> > prevent the termination of an X session even if CTRL+ALT+FN etc gets
> > console access?
> 
> I've always used "startx & exit", and it works perfectly.
> It doesn't prevent the termination of an X session, but if it's terminated 
> you get a logon prompt as if you had just booted the machine.

Indeed.

I'll return to the suggestion to use DontVTSwitch. With a locked sceen
it is effective in preventing switching to a console with CTRL+ALT+FN
and chvt even if the sudo timeout hasn't been reached.

An unlocked screen plus 'ps ax' and 'kill' enable the bringing down of X
no matter what the length of the sudo timeout is or whether DontVTSwitch
is operational.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321154029.gc4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Lisi Reisz]

On Friday 21 March 2014 11:06:03 Robin wrote:
> If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

The default on Debian since I have been using it is that the root 
password is required for access via single user mode.  This may be 
affected by the fact that I always set a root password.

But physical access would also allow the use of a live cd. 

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201403211524.28403.lisi.re...@gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

berenger.mo...@neutralite.org writes:
 > 
 > 
 > Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :
 > > berenger.mo...@neutralite.org writes:
 > >  > Can't ~/.xinitrc force startx to logout?
 > >
 > > H, maybe if you start x with . xinitrc .

Me _idiot_! (despite the triple expresso shot).

I should have written "if you start X with «. startx» with a blank
within the . and the "startx" word.

The .xinitrc file can not do too much for a logout issue.

When  it terminates,  X dies  and this  seems to  show that  the shell
running .xinitrc is a child of X process, and the X process is a child
of the login shell. The only mean for .xinitrc to kill its grandparent
is by means of a well aimed kill -9 :).

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.16327.236829.55...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Valerio Vanni]

"Brian"  ha scritto nel messaggio
news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk

> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?

I've always used "startx & exit", and it works perfectly.
It doesn't prevent the termination of an X session, but if it's terminated 
you get a logon prompt as if you had just booted the machine.




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lghej2$ven$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Robin]

On 21 March 2014 11:18, Darac Marjal  wrote:
> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
>> I may have missed something. If someone has physical access to your
>> machine can't they just power off and go into single user mode and
>> change the root password?
>
> Maybe, maybe not. Console access doesn't have to mean complete access.
> The scenario I always have in my head for these sorts of things is a
> Computer Lab at a university/college. You can allow anyone to come up
> and use the machine via the keyboard/mouse/VDU attached to it, but to
> counter the attack vector you mention, you simply lock the computer
> itself away in a secure cage under the desk. That also stops the
> "security vector" of someone simply picking up the machine and walking
> off with it ;)
>

Sorry my mail was a bit terse. I was referring to whether a DM is more
secure than startx when there is physical access to a machine.

-- 
rob


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caozwb-pam8gh4dtbf-pgvfu+sueuqjfaxwp_tjyasnvzlkj...@mail.gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[berenger . morel]

Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :

berenger.mo...@neutralite.org writes:
 > Can't ~/.xinitrc force startx to logout?

H, maybe if you start x with . xinitrc . Would you forgive me if 
I

don't do the test right now and continue to do the work I am paid for
:) ?


Currently, you do not, except if you are paid to do some support on 
debian ml. If so, I'm really jealous :D


Except that point, no problem for me, if you do not try now.
I did a very quick test, but it did not worked. Now, I'm not sure that 
I've modified the good file: when doing startx with root ( just to try, 
I do not usually do this ) my window manager is started correctly, and 
there is no .xinitrc there. But if you want to play with this 
possibility, feel free to do so, I'm really interested.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/89eee6b2e416d81d7b29dad50e67b...@neutralite.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

berenger.mo...@neutralite.org writes:
 > Can't ~/.xinitrc force startx to logout?

H, maybe if you start x with . xinitrc . Would you forgive me if I
don't do the test right now and continue to do the work I am paid for
:) ?

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21292.13933.899681.244...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[berenger . morel]

Le 20.03.2014 02:44, Zenaan Harkness a écrit :
Yeah, when making a machine for a less technical or less 
command-prompt

comfortable person, I like to have it boot into GUI via the desktop
manager. But when setting it up for myself or for people technically
sharp enough to log in and then type "startx" (and people you can
trust with the command prompt), I like to boot to the command 
prompt.


When logging in at the Linux console (on current kernels at least),
then running startx, there is a security problem:

Anyone with physical access to your computer could:

a) logout of your gui session (if it's not screensaver locked), 
taking

them back to your command line, and depending on your settings of
/etc/sudoers tty_tickets or respectively !tty_tickets setting - see
man sudoers) might give them instant root access;
either way, mischief may ensure.

b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your 
gui

session, notwithstanding if you even have it gui locked


SO: what to do?

What I did for a while was:
a) log in to Linux console
b) startx; exit

This way, when the gui (X in this case) exits for any reason, then 
the

console shell session logs out automatically.

That's fine, but requires more typing, and remembering to add the
extra "; exit" command.

So to optimize, simply put the sequency "startx; exit" (or similar)
into a shell function - I use the name "se" since it's less to type 
:)


So now I use:
a) log in to Linux console
b) se

Happy and safe sessions to all,
Zenaan


Can't ~/.xinitrc force startx to logout?
And about TTYs, I guess that, for most users, the easiest thing to do 
is to disable all but one for the usual runlevel. ( /etc/inittab could 
help )



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/810fee07a22880f1c573348502743...@neutralite.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 11:18:19 +, Darac Marjal wrote:

> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root password?
> 
> Maybe, maybe not. Console access doesn't have to mean complete access.
> The scenario I always have in my head for these sorts of things is a
> Computer Lab at a university/college. You can allow anyone to come up
> and use the machine via the keyboard/mouse/VDU attached to it, but to
> counter the attack vector you mention, you simply lock the computer
> itself away in a secure cage under the desk. That also stops the
> "security vector" of someone simply picking up the machine and walking
> off with it ;)

For the situation when X is started with startx would 'startx & exit'
prevent the termination of an X session even if CTRL+ALT+FN etc gets
console access?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21032014113647.c62190855...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Darac Marjal]

On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?

Maybe, maybe not. Console access doesn't have to mean complete access.
The scenario I always have in my head for these sorts of things is a
Computer Lab at a university/college. You can allow anyone to come up
and use the machine via the keyboard/mouse/VDU attached to it, but to
counter the attack vector you mention, you simply lock the computer
itself away in a secure cage under the desk. That also stops the
"security vector" of someone simply picking up the machine and walking
off with it ;)



signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Robin]

I may have missed something. If someone has physical access to your
machine can't they just power off and go into single user mode and
change the root password?

-- 
rob


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caozwb-q+wwdadb6nz0rrhprqvmzc0_y3oi36v55a2h7yrfo...@mail.gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 10:24:54 +, Jonathan Dowland wrote:

> On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> > In an xterm (with or without using DontVTSwitch):
> > 
> >brian@localhost:~$ chvt 4
> >Couldn't gat a file descriptor referring to the console
> > 
> > Doubt no longer. :)
> 
> Try via sudo. (risk reduced to: X session left open, terminal left open,
> non-expired sudo ticket in that terminal)

Didn't think of that. You're correct, of course. Thanks for the
explanation.

> I'm still sure there will be many other ways to do it, although they may
> require privileges to do so.

I'm convinced.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21032014103947.7b37bc831...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Darac Marjal]

On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > 
> > You can access the console X was started from even when the machine is
> > locked.
> 
> Seriously? I'd find that to be a severe bug in the said locking 
> application.

It's a feature of linux being multi-user. You come up to a machine
that's running Xscreensaver (et al.) change to another VT, login there
and start another X server. GDM can facilitate this with the Switch User
functionality, but it's perfectly normal behaviour even without.

If you don't want people terminating your X session from the console, I
think the best solution is to use a display manager, which re-uses the
VT, and to turn on DontZap.



signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jonathan Dowland]

On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> In an xterm (with or without using DontVTSwitch):
> 
>brian@localhost:~$ chvt 4
>Couldn't gat a file descriptor referring to the console
> 
> Doubt no longer. :)

Try via sudo. (risk reduced to: X session left open, terminal left open,
non-expired sudo ticket in that terminal)

I'm still sure there will be many other ways to do it, although they may
require privileges to do so.

Having said all the above, I'd advocate using a display manager for the
vast majority of people.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321102454.ga16...@bryant.redmars.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Fri 21 Mar 2014 at 09:24:21 +, Jonathan Dowland wrote:

> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > through 12, respectively. This can be disabled with the
> > DontVTSwitch xorg.conf(5) file  option.
> 
> I doubt that stops e.g. chvt(1) from working. I'm sure there are a
> myriad other ways to switch VT from within the X session, too.

In an xterm (with or without using DontVTSwitch):

   brian@localhost:~$ chvt 4
   Couldn't gat a file descriptor referring to the console

Doubt no longer. :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321095203.gb4...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> 
> You can access the console X was started from even when the machine is
> locked.

Seriously? I'd find that to be a severe bug in the said locking 
application.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Jonathan Dowland]

On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
>Ctrl+Alt+F1...F12
> For systems with virtual terminal support, these keystroke
> combinations are used to switch to virtual terminals 1
> through 12, respectively. This can be disabled with the
> DontVTSwitch xorg.conf(5) file  option.

I doubt that stops e.g. chvt(1) from working. I'm sure there are a
myriad other ways to switch VT from within the X session, too.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321092421.ga15...@bryant.redmars.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Gian Uberto Lauri]

Andrei POPESCU writes:

 > 3. any user, with or without root access, who doesn't lock his 
 > workstation as needed[1] deserves his fate.

And does not uses startx; exit

You can access the console X was started from even when the machine is
locked.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21291.64953.782916.83...@mail.eng.it

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Andrei POPESCU]

On Jo, 20 mar 14, 12:44:21, Zenaan Harkness wrote:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.

1. tty_tickets is enabled by default

2. even if you do disable it, if my understanding of the man page is 
correct, the attacker doesn't need the console, but can use any terminal 
emulator (as another poster already mentioned)

3. any user, with or without root access, who doesn't lock his 
workstation as needed[1] deserves his fate.

[1] IMVHO it's reasonable to have different policies at home compared to 
publicly installed (work) computers, but always locking your workstation 
is probably a good habit to acquire.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Wed 19 Mar 2014 at 22:48:49 -0400, Steve Litt of Troubleshooters.Com wrote:

> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
> 
> > SO: what to do?
> > 
> > What I did for a while was:
> > a) log in to Linux console
> > b) startx; exit
> 
> Outstanding! I'm going to start doing that. Thanks.

This looks like a solution in search of a problem. Instant root access
would be available within X if tty_tickets is set off.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140320162709.gq26...@copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Brian]

On Thu 20 Mar 2014 at 12:44:21 +1100, Zenaan Harkness wrote:

> > Yeah, when making a machine for a less technical or less command-prompt
> > comfortable person, I like to have it boot into GUI via the desktop
> > manager. But when setting it up for myself or for people technically
> > sharp enough to log in and then type "startx" (and people you can
> > trust with the command prompt), I like to boot to the command prompt.
> 
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked

Use the Force, Zenaan:

   man xorg

and then

   Ctrl+Alt+F1...F12
For systems with virtual terminal support, these keystroke
combinations are used to switch to virtual terminals 1
through 12, respectively. This can be disabled with the
DontVTSwitch xorg.conf(5) file  option.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20032014141516.099233063...@desktop.copernicus.demon.co.uk

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Curt]

On 2014-03-20, Vincent Lefevre  wrote:
>
> For instance, type:
>
>   sleep 2; exit
>
> and Ctrl-C just after. The "sleep 2" is interrupted, but "exit"
> isn't run.
>
> You could still do "exec startx", but this may not be OK if you
> want *logout files to be sourced for clean-up.

Not using sudo would maybe be the most robust solution.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlilg5d.233.cu...@einstein.electron.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Vincent Lefevre]

On 2014-03-20 12:44:21 +1100, Zenaan Harkness wrote:
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked
> 
> 
> SO: what to do?
> 
> What I did for a while was:
> a) log in to Linux console
> b) startx; exit

Does it really solve the problem?

For instance, type:

  sleep 2; exit

and Ctrl-C just after. The "sleep 2" is interrupted, but "exit"
isn't run.

You could still do "exec startx", but this may not be OK if you
want *logout files to be sourced for clean-up.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140320085249.ga31...@xvii.vinc17.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Scott Ferguson]

On 20/03/14 13:48, Steve Litt of Troubleshooters.Com wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
> 
>>> Yeah, when making a machine for a less technical or less
>>> command-prompt comfortable person, I like to have it boot into GUI
>>> via the desktop manager. But when setting it up for myself or for
>>> people technically sharp enough to log in and then type
>>> "startx" (and people you can trust with the command prompt), I like
>>> to boot to the command prompt.
>>
>> When logging in at the Linux console (on current kernels at least),
>> then running startx, there is a security problem:
>>

> 
> Of course, if a badguy has physical access, then you're pretty much
> screwed anyway: 

Yes. And no.
Contrary to "popular" "belief" - if someone has physical access it's
*not* "game over".
The plural of anecdote is not fact, possible != probable, and probable
!= certain. :)

If someone breaks into your house they could break into your safe. It's
not reason to not have a safe.



Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532a82d8.6090...@gmail.com

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

On 3/20/14, Zenaan Harkness  wrote:
> On 3/20/14, Steve Litt of Troubleshooters.Com  wrote:
>> On Thu, 20 Mar 2014 12:44:21 +1100
>> Zenaan Harkness  wrote:
>>
>>> > Yeah, when making a machine for a less technical or less
>>> > command-prompt comfortable person, I like to have it boot into GUI
>>> > via the desktop manager. But when setting it up for myself or for
>>> > people technically sharp enough to log in and then type
>>> > "startx" (and people you can trust with the command prompt), I like
>>> > to boot to the command prompt.
>>>
>>> When logging in at the Linux console (on current kernels at least),
>>> then running startx, there is a security problem:
>>>
>>> Anyone with physical access to your computer could:
>>>
>>> a) logout of your gui session (if it's not screensaver locked), taking
>>> them back to your command line, and depending on your settings of
>>> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
>>> man sudoers) might give them instant root access;
>>> either way, mischief may ensure.
>>>
>>> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
>>> session, notwithstanding if you even have it gui locked
>>>
>>>
>>> SO: what to do?
>>>
>>> What I did for a while was:
>>> a) log in to Linux console
>>> b) startx; exit
>>>
>>> This way, when the gui (X in this case) exits for any reason, then the
>>> console shell session logs out automatically.
>>>
>>> That's fine, but requires more typing, and remembering to add the
>>> extra "; exit" command.
>>>
>>> So to optimize, simply put the sequency "startx; exit" (or similar)
>>> into a shell function - I use the name "se" since it's less to type :)
>>>
>>> So now I use:
>>> a) log in to Linux console
>>> b) se
>>>
>>> Happy and safe sessions to all,
>>> Zenaan
>>
>> Outstanding! I'm going to start doing that. Thanks.
>
> You're welcome.
>
>> What shellscript contains the se function on your system?
>
> My system is not relevant. The point is, it needs to be in one of your
> startup scripts. If you use the GNU Bash shell, then you might try
> ~/.bashrc
>
> Other shells might have different function declaration syntax, and
> different put-this-function-in-my-environment syntax.
>
> I have attached my ~/lib/libintrospect.sh file and added the se
> function to the bottom, so you can see how this works for bash,
> including a function which can be used to export all declared
> functions - you may of course only want to export one or two
> functions, but at least this shows you how to do that.
>
> I plan to tidy up my bash libraries and upload them - hopefully this year.
>
>
>> Of course, if a badguy has physical access, then you're pretty much
>> screwed anyway: If you don't have a bios password they can boot System
>> Rescue CD, mount your root partition, delete the x in the second field
>> of root's record (or your record if there's no root), log in, press
>> enter, log in, change the password to something they like, and have
>> their way with the machine.
>
> Of course. This is simply one extra layer of protection, and will only
> protect you against a quick-and-dirty type attach which might
> otherwise be done in just a few seconds. This script can prevent that
> type of physical-access attack, so it's much better than nothing.
>
> Enjoy,
> Zenaan

I'm not sure it came through, I just got this error:
Subject: [MailServer Notification]Attachment Blocking Notification
From: Administrator 
Date: Thu, Mar 20, 2014 at 2:56 PM
To: z...@freedbms.net

The libintrospect.sh has been blocked,
and Quarantine entire message has been taken on 3/20/2014 5:55:46 AM.

Message details:
Server: HEMATIT
Sender: z...@freedbms.net;
Recipient: debian-user@lists.debian.org;
Subject: Re: Security Implications of running startx from command line -
was Re: Startx: was Great Debian experience
Attachment name: libintrospect.sh

If so, then here's the libintrospect.sh file for cutting and pasting:
[ -n "$ZLIB_INTROSPECT" ] && return || typeset -xr ZLIB_INTROSPECT=0

# Copyright 2014, Zenaan Harkness, g...@freedbms.net

# License: This file may be distributed under the terms of the GNU General
# Public License, either version 3, or at your option, any later version.

# WARNING: Distributed with no warranty of any sort, implied or otherwise.

##
# library: libi

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

On 3/20/14, Steve Litt of Troubleshooters.Com  wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness  wrote:
>
>> > Yeah, when making a machine for a less technical or less
>> > command-prompt comfortable person, I like to have it boot into GUI
>> > via the desktop manager. But when setting it up for myself or for
>> > people technically sharp enough to log in and then type
>> > "startx" (and people you can trust with the command prompt), I like
>> > to boot to the command prompt.
>>
>> When logging in at the Linux console (on current kernels at least),
>> then running startx, there is a security problem:
>>
>> Anyone with physical access to your computer could:
>>
>> a) logout of your gui session (if it's not screensaver locked), taking
>> them back to your command line, and depending on your settings of
>> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
>> man sudoers) might give them instant root access;
>> either way, mischief may ensure.
>>
>> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
>> session, notwithstanding if you even have it gui locked
>>
>>
>> SO: what to do?
>>
>> What I did for a while was:
>> a) log in to Linux console
>> b) startx; exit
>>
>> This way, when the gui (X in this case) exits for any reason, then the
>> console shell session logs out automatically.
>>
>> That's fine, but requires more typing, and remembering to add the
>> extra "; exit" command.
>>
>> So to optimize, simply put the sequency "startx; exit" (or similar)
>> into a shell function - I use the name "se" since it's less to type :)
>>
>> So now I use:
>> a) log in to Linux console
>> b) se
>>
>> Happy and safe sessions to all,
>> Zenaan
>
> Outstanding! I'm going to start doing that. Thanks.

You're welcome.

> What shellscript contains the se function on your system?

My system is not relevant. The point is, it needs to be in one of your
startup scripts. If you use the GNU Bash shell, then you might try
~/.bashrc

Other shells might have different function declaration syntax, and
different put-this-function-in-my-environment syntax.

I have attached my ~/lib/libintrospect.sh file and added the se
function to the bottom, so you can see how this works for bash,
including a function which can be used to export all declared
functions - you may of course only want to export one or two
functions, but at least this shows you how to do that.

I plan to tidy up my bash libraries and upload them - hopefully this year.


> Of course, if a badguy has physical access, then you're pretty much
> screwed anyway: If you don't have a bios password they can boot System
> Rescue CD, mount your root partition, delete the x in the second field
> of root's record (or your record if there's no root), log in, press
> enter, log in, change the password to something they like, and have
> their way with the machine.

Of course. This is simply one extra layer of protection, and will only
protect you against a quick-and-dirty type attach which might
otherwise be done in just a few seconds. This script can prevent that
type of physical-access attack, so it's much better than nothing.

Enjoy,
Zenaan


libintrospect.sh
Description: Bourne shell script

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Steve Litt of Troubleshooters.Com]

On Thu, 20 Mar 2014 12:44:21 +1100
Zenaan Harkness  wrote:

> > Yeah, when making a machine for a less technical or less
> > command-prompt comfortable person, I like to have it boot into GUI
> > via the desktop manager. But when setting it up for myself or for
> > people technically sharp enough to log in and then type
> > "startx" (and people you can trust with the command prompt), I like
> > to boot to the command prompt.
> 
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
> 
> Anyone with physical access to your computer could:
> 
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see
> man sudoers) might give them instant root access;
> either way, mischief may ensure.
> 
> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
> session, notwithstanding if you even have it gui locked
> 
> 
> SO: what to do?
> 
> What I did for a while was:
> a) log in to Linux console
> b) startx; exit
> 
> This way, when the gui (X in this case) exits for any reason, then the
> console shell session logs out automatically.
> 
> That's fine, but requires more typing, and remembering to add the
> extra "; exit" command.
> 
> So to optimize, simply put the sequency "startx; exit" (or similar)
> into a shell function - I use the name "se" since it's less to type :)
> 
> So now I use:
> a) log in to Linux console
> b) se
> 
> Happy and safe sessions to all,
> Zenaan

Outstanding! I'm going to start doing that. Thanks.

What shellscript contains the se function on your system?

Of course, if a badguy has physical access, then you're pretty much
screwed anyway: If you don't have a bios password they can boot System
Rescue CD, mount your root partition, delete the x in the second field
of root's record (or your record if there's no root), log in, press
enter, log in, change the password to something they like, and have
their way with the machine.

But I still like your se, and will do that.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140319224849.1b1aaec5@mydesk

Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Zenaan Harkness]

> Yeah, when making a machine for a less technical or less command-prompt
> comfortable person, I like to have it boot into GUI via the desktop
> manager. But when setting it up for myself or for people technically
> sharp enough to log in and then type "startx" (and people you can
> trust with the command prompt), I like to boot to the command prompt.

When logging in at the Linux console (on current kernels at least),
then running startx, there is a security problem:

Anyone with physical access to your computer could:

a) logout of your gui session (if it's not screensaver locked), taking
them back to your command line, and depending on your settings of
/etc/sudoers tty_tickets or respectively !tty_tickets setting - see
man sudoers) might give them instant root access;
either way, mischief may ensure.

b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui
session, notwithstanding if you even have it gui locked


SO: what to do?

What I did for a while was:
a) log in to Linux console
b) startx; exit

This way, when the gui (X in this case) exits for any reason, then the
console shell session logs out automatically.

That's fine, but requires more typing, and remembering to add the
extra "; exit" command.

So to optimize, simply put the sequency "startx; exit" (or similar)
into a shell function - I use the name "se" since it's less to type :)

So now I use:
a) log in to Linux console
b) se

Happy and safe sessions to all,
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnssdt+5w-teaijnkfnkl0tmclf4ljuiokkw+oxdfiei...@mail.gmail.com