local user get created magically ! system hacked ?

Jehan Procaccia jehan.procaccia at tem-tsp.eu
Wed Dec 4 22:35:13 UTC 2013


Le 04/12/2013 23:04, Rick Stevens a écrit :
> On 12/04/2013 01:42 PM, Jehan Procaccia issued this missive:
>> Le 04/12/2013 18:51, Rick Stevens a écrit :
>>> On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
>>>> On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
>>>>
>>>>> hello
>>>>> I use about a hundred fedora19 stations in computer labs at our 
>>>>> school
>>>>> users accounts comes from an ldap directory and the homedir is
>>>>> automounted via NFS.
>>>>> However, recently I noticed that on some stations, local user account
>>>>> had been created !
>>>>> looking at the log file, I discovered in /var/log/secure something 
>>>>> like
>>>>> this:
>>>>>
>>>>> /accounts-daemon: request by system-bus-name ::1.733
>>>>> [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user
>>>>> 'foobar'//
>>>>> //useradd[29724]: new group: name=foobar, GID=1001//
>>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user:
>>>>> name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash//
>>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 
>>>>> 'susana' to
>>>>> group 'wheel'//
>>>>> //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 
>>>>> 'susana' to
>>>>> shadow group 'wheel'/
>>>>>
>>>>> Scary ! how comes gnome-initial-setup could create users, and morever
>>>>> add them to the wheel group !
>>>>> could it be a bug in /gnome-initial-setup , /a feature side effect 
>>>>> ? or
>>>>> our students found a "back door" ?
>>>>> any suggestion greatly appreciated .
>>>>
>>>> See what running
>>>>
>>>>    /usr/libexec/gnome-initial-setup --force-new-user
>>>>
>>>> does on one of your installed machines, where 'susana' has not been
>>>> active
>>>> before. Normally, it would prompt for the root password before
>>>> creating a
>>>> new account, but perhaps something else happens with your setup.
>>>
>>> In the old days, a process called 'firstboot' was run immediately upon
>>> the first boot after a fresh install. firstboot was responsible for a
>>> number of things, but one of them was setting up the first user account
>>> and adding it to the "wheel" group because it was expected to be the
>>> administrator's account. firstboot never asked for the root password as
>>> it assumed it was being run as part of the install process by a human
>>> who installed the system and would already know the root password.
>>> Hence, the first user account was, by default, an administrative
>>> account in the wheel group who could sudo any command.
>>>
>>> Once firstboot had been run, it disconnected itself from the boot
>>> process by deleting a file in the root of the filesystem that an init
>>> script looked for. If the file wasn't there, firstboot wouldn't run.
>>>
>>> I don't run gnome (because it's so damned bloated), so I'm not sure 
>>> what
>>> gnome-initial-setup does, but I suspect it took its cues from the old
>>> firstboot mechanism. If so, then what probably happened is that the
>>> install process was interrupted after the OS was installed. Whoever did
>>> the install did NOT go through the first boot. "susana" was probably 
>>> the
>>> first person to see the machine, booted it and got the first boot 
>>> thing.
>>> She added herself, not knowing exactly what this meant at the time. I
>>> doubt she was being malicious.
>>>
>>> These are just guesses, mind you, but seem to be a likely scenario.
>> This senario is very possible
>> we installed our station automatically (cobbler2 kickstart + cfengine3
>> for post config) and remotely , it is possible that some stations didn't
>> finish correctly the install process
>> and that the "firstboot" process didn't finished properly .
>> Do you know how to check on a station if the "firstboot process" state
>> is still "on" or "off", what about that mysterious file you mention
>> "/it disconnected itself from the boot //
>> //process by deleting a file in the root of the filesystem that an 
>> init //
>> //script looked for. If the file wasn't there, firstboot wouldn't run./"
>> what is its name ?
>
> On old systems (e.g. CentOS 5/6), the /etc/rc.d/init.d/firstboot script
> looked for an /etc/sysconfig/firstboot file. That file would contain
> either
>
>     RUN_FIRSTBOOT=YES
>
> to run firstboot, or
>
>     RUN_FIRSTBOOT=NO
>
> so it didn't run. Also, if the /etc/reconfigSys file was present, then
> firstboot would be run with the "--reconfig" option.
>
> Again, I don't run gnome (I'm an XFCE user) so I don't know if it's a
> systemd service that should run and then remove itself or what. To be
> honest, I haven't done a fresh Fedora installation (F18 or F19) in a
> while (I've "fedup"ped already installed systems).
>
>> could this pb be relatated to:
>> https://bugzilla.redhat.com/show_bug.cgi?id=968582
>> not sure, because on a station that has the pb it seems disabled:
>>
>> # /bin/systemctl status initial-setup-text.service
>> initial-setup-text.service - Initial Setup configuration program 
>> (text mode)
>>     Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service;
>> disabled)
>>     Active: inactive (dead)
>
> It'd be interesting to bring up a system and see if that service is set
> to start on the first boot after an install.
>
>> and I do run my kickstart with
>> firstboot --disabled
>
> That may not have an effect as I don't think there is a "firstboot"
> thing since we went to systemd/systemctl rather than the classic init
> scripts. I think that initial-setup-text.service and/or the 
> gnome-initial-setup thing may have replaced that. Since I never installed
> Gnome, I don't have the gnome-initial-setup program nor do I seem to
> have a initial-setup-text.service file.
>
> I wish I could be of more help.
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital ricks at alldigital.com -
> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
> - -
> -   UNIX is actually quite user friendly.  The problem is that it's  -
> -              just very picky of who its friends are!               -
> ----------------------------------------------------------------------
yes I suspect that in F19 the "firstboot" machnism might have change a 
lot from older versions

my kicstart file is programmed to set a root password and create a local 
user account,
Although I set in the kickstart file
firstboot --disabled
I took that option from a older kickstart (F13 I think) installed, and 
maybe it has not the exepected effect anymore ...

perhaps there had been a strange set of events that prevented the 
install process to terminate properly,

Anyway, /usr/libexec/gnome-initial-setup can be run anytime be any user, 
but I am expecting that unprivilege user cannot add local users !
on a machine that is installed properly , it allows unprivilege users 
only to create "remote = google, facebook ..." accounts, not local .

Is someone on the list, knows what is the status of "firstboot" process 
on F19 machines ? how can I check its state ?

would remove gnome-initial-setup package be a solution without bad side 
effect ?

Thanks .




More information about the users mailing list