CN116432166A - Authentication method and device of daemon, electronic equipment and readable storage medium - Google Patents
Authentication method and device of daemon, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN116432166A CN116432166A CN202310328149.1A CN202310328149A CN116432166A CN 116432166 A CN116432166 A CN 116432166A CN 202310328149 A CN202310328149 A CN 202310328149A CN 116432166 A CN116432166 A CN 116432166A
- Authority
- CN
- China
- Prior art keywords
- calling party
- daemon
- calling
- party process
- determining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 400
- 230000008569 process Effects 0.000 claims abstract description 355
- 238000013475 authorization Methods 0.000 claims description 24
- 230000006399 behavior Effects 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 6
- 238000012546 transfer Methods 0.000 claims description 5
- 230000007246 mechanism Effects 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 7
- 230000009471 action Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 239000011230 binding agent Substances 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a daemon authentication method, a daemon authentication device, electronic equipment and a readable storage medium, wherein the daemon authentication method comprises the following steps: determining whether the calling party process is a daemon process; determining that the calling party process is a daemon process, and judging whether the calling party process is in a preset white list or not; determining that the calling party process is not in a preset white list, and popping up an authentication interface; the display information of the authentication interface comprises: the name of the caller process and the directory path of the caller process; and responding to the authority selection behavior of the user on the authentication interface, and executing corresponding process calling operation. The method can solve the problem that a daemon authentication mechanism is lacked in the prior art.
Description
Technical Field
The present disclosure relates to the field of authentication technologies, and in particular, to a daemon authentication method, apparatus, electronic device, and readable storage medium.
Background
Authentication refers to verifying whether a user has rights to access a system. The authentication mode of the process of the APP (Application) is that the UID of the calling party process is obtained as a parameter in the function of the called party process through a binder public interface, and the UID and the specific authority are transmitted to the authority management service for authentication. The authentication mode of the non-application program process is relative to the APP application program process, and the non-application program process generally refers to a background process in the android operating system, and is also called a daemon process. Daemons are typically preset into the system at compile time, unlike application processes, which, as system integration becomes more and more complex, particularly in large complex projects, there are numerous suppliers and implementers, with the security of the preset daemons then being at great risk, since these daemons are always running by default and have high rights, and once exploited, consequences are not envisaged, such as vulnerabilities of the system being exploited by hackers to install some dangerous daemons, which can lead to security risks.
In the related art, an authentication manner is provided for a process of an application program, but an authentication mechanism for a daemon process is lacking.
Disclosure of Invention
In order to solve the technical problems or at least partially solve the technical problems, the application provides an authentication method of a daemon, which solves the problem that a daemon authentication mechanism is lacked in the prior art.
In order to achieve the above object, the embodiment of the present application provides the following technical solutions:
in a first aspect, embodiments of the present application provide a daemon authentication method, the method comprising:
determining whether the calling party process is a daemon process;
determining that the calling party process is a daemon process, and judging whether the calling party process is in a preset white list or not;
determining that the calling party process is not in a preset white list, and popping up an authentication interface; the display information of the authentication interface comprises: the name of the caller process and the directory path of the caller process;
and responding to the authority selection behavior of the user on the authentication interface, and executing corresponding process calling operation.
As an optional implementation manner of the embodiment of the present application, the determining whether the calling party process is a daemon includes:
acquiring identification information of a calling party process; the identification information of the calling party process comprises: a user identifier UID;
and determining whether the calling process is a daemon according to the identification information of the calling process.
As an optional implementation manner of the embodiment of the present application, the determining, according to the identification information of the caller process, whether the caller process is a daemon includes:
if the user identifier of the calling party process is smaller than a preset value, determining that the calling party process is a daemon;
and if the user identifier of the calling party process is larger than or equal to a preset value, determining that the calling party process is a process of the application program.
As an optional implementation manner of the embodiment of the present application, the determining whether the caller process is in a preset whitelist further includes:
and if the calling party process is in the preset white list, allowing the calling party process to complete calling operation.
As an optional implementation manner of the embodiment of the present application, after performing the corresponding process calling operation in response to the permission selection behavior of the user, the method further includes:
storing attribute information of the calling party process into a permission database;
the process attribute information of the calling party process comprises: the method comprises the steps of MD5 value of a calling party process file, name of the calling party process, path of the calling party process, authority of the calling party process and authority authorization state of the calling party process.
As an optional implementation manner of the embodiment of the present application, the method further includes:
acquiring the authority authorization state of the target daemon according to the authority database;
and determining whether to execute corresponding process calling operation according to the authority authorization state of the target daemon.
As an optional implementation manner of the embodiment of the present application, the determining whether the caller process is in a preset whitelist further includes:
acquiring the UID of the calling party process;
if the UID of the calling party process is a first preset value, replacing the UID of the calling party process with a second preset value of a transfer layer;
when an authorization request sent by a process corresponding to the UID of the second preset value is received, the PID of the calling party process is obtained;
and determining whether the calling process is in a preset white list according to the PID of the calling process.
In a second aspect, an embodiment of the present application provides an authentication apparatus of a daemon, including:
the determining module is used for determining whether the calling party process is a daemon process or not;
the judging module is used for determining that the calling party process is a daemon process and judging whether the calling party process is in a preset white list or not;
the selection module is used for determining that the calling party process is not in a preset white list and popping up an authentication interface; the display information of the authentication interface comprises: the name of each daemon and the directory path of each daemon;
and the execution module is used for responding to the authority selection behavior of the user on the authentication interface and executing corresponding process calling operation.
As an optional implementation manner of the embodiment of the present application, the determining module includes:
the acquisition unit is used for acquiring the identification information of the calling party process; the identification information of the calling party process comprises: a user identifier UID;
and the determining unit is used for determining whether the calling party process is a daemon according to the identification information of the calling party process.
As an optional implementation manner of the embodiment of the present application, the determining unit is specifically configured to:
if the user identifier of the calling party process is smaller than a preset value, determining that the calling party process is a daemon;
and if the user identifier of the calling party process is larger than or equal to a preset value, determining that the calling party process is a process of the application program.
As an optional implementation manner of the embodiment of the present application, the determining module is further configured to:
and if the calling party process is in the preset white list, allowing the calling party process to complete calling operation.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes:
the storage module is used for storing the attribute information of the calling party process into a permission database;
the process attribute information of the calling party process comprises: the method comprises the steps of MD5 value of a calling party process file, name of the calling party process, path of the calling party process, authority of the calling party process and authority authorization state of the calling party process.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes:
the state acquisition module is used for acquiring the authority authorization state of the target daemon according to the authority database;
and the processing module is used for determining whether to execute corresponding process calling operation according to the authority authorization state of the target daemon process.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes an analysis module, where the analysis module is specifically configured to:
acquiring the UID of the calling party process;
if the UID of the calling party process is a first preset value, replacing the UID of the calling party process with a second preset value of a transfer layer;
when an authorization request sent by a process corresponding to the UID of the second preset value is received, the PID of the calling party process is obtained;
and determining whether the calling process is in a preset white list according to the PID of the calling process.
In a third aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the processor implements the authentication method of the daemon according to the first aspect or any implementation manner of the first aspect when executing the computer program.
In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor implements the daemon authentication method according to the first aspect or any implementation manner of the first aspect.
The authentication method of the daemon process comprises the steps of firstly determining whether a calling party process is the daemon process, judging whether the calling party process is in a preset white list after determining that the calling party process is the daemon process, popping up an authentication interface when determining that the calling party process is not in the preset white list, and executing corresponding process calling operation in response to authority selection behaviors of a user at the authentication interface. After determining that the calling party process is the daemon process, judging whether the calling party process is in a preset white list or not, and if the calling party process is not in the preset white list, popping up an authentication interface to enable a user to determine whether the calling party process is safe and reliable according to the name of the calling party process in the authentication interface and the directory path of the calling party process, and finally executing corresponding process calling operation based on authority selection behavior of the user in the authentication interface, so that authentication of the daemon process is realized.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the description of the embodiments or the prior art will be briefly described below, and it will be obvious to those skilled in the art that other drawings can be obtained from these drawings without inventive effort.
FIG. 1 is a flow diagram of a daemon authentication method in one embodiment;
FIG. 2 is a diagram of an authentication interface of a daemon in one embodiment;
FIG. 3 is a flow chart of a daemon authentication method in another embodiment;
FIG. 4 is a schematic diagram of an authentication device of a daemon in one embodiment;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order that the above objects, features and advantages of the present application may be more clearly understood, a further description of the aspects of the present application will be provided below. It should be noted that, in the case of no conflict, the embodiments of the present application and the features in the embodiments may be combined with each other.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure, but the present application may be practiced otherwise than as described herein; it will be apparent that the embodiments in the specification are only some, but not all, embodiments of the application.
Relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
In the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion. Furthermore, in the description of the embodiments of the present application, unless otherwise indicated, the meaning of "plurality" means two or more.
The overall conception of the embodiment of the application is as follows: after determining that the calling party process is a daemon process, judging whether the calling party process is in a preset white list, if yes, popping up an authentication interface to enable a user to determine whether the calling party process is safe and reliable according to the name of the calling party process in the authentication interface and the directory path of the calling party process, and finally executing corresponding process calling operation based on authority selection behavior of the user in the authentication interface, so that authentication of the daemon process is realized.
In one embodiment, as shown in fig. 1, there is provided an authentication method of a daemon, the authentication method of the daemon comprising the steps of:
s11, determining whether the calling party process is a daemon process.
Among them, daemons are a class of processes that run in the background and are not controlled by any terminal for performing specific system tasks, many of which start up at system boot time and run until the system shuts down. And a part of daemons are started when needed, and the daemons automatically end after completing tasks. Daemons are typically pre-set into the system at compile time, unlike processes in applications, when the system is started, the initial program starts them according to the characteristics and definitions of android.
Specifically, since the calling process may be a daemon process, it may also be a process of an application program. Therefore, it is first necessary to determine whether the caller process is a daemon.
In some embodiments, the step S11, determining whether the calling process is a daemon, may be implemented by the following steps S111-S112:
s111, acquiring identification information of a calling party process.
Wherein the identification information of the caller process includes a user identifier UID.
Specifically, a UID (User Identifier) indicates which User has run the program in the Linux system, and is mainly used for rights management. However, UID represents different meanings in the android system, and since the android is a single-user system, the UID is used for realizing data sharing at this time, that is, the android is assigned to different UIDs for each application.
Illustratively, if the UID of the caller process is equal to 0, the caller process is a ROOT user; if the UID of the caller process is equal to 1000, the caller process is a SYSTEM user. The ROOT user is also called a ROOT user, is the only super user in Unix and Unix-like systems (such as Linux, QNX and the like) and Android and iOS mobile equipment systems, and can perform reading, writing and executing operations on the ROOT directory. The SYSTEM user is a process controlled by the SYSTEM and is not manually controlled.
S112, determining whether the calling process is a daemon according to the identification information of the calling process.
In some embodiments, the step S112, determining whether the calling process is a daemon according to the identification information of the calling process may be implemented as follows:
and if the user identifier of the calling party process is smaller than a preset value, determining that the calling party process is a daemon.
And if the user identifier of the calling party process is larger than or equal to a preset value, determining that the calling party process is a process of the application program.
Specifically, since the UID range of the process of the application is 10000 or more, the application is a daemon process. The preset value may take 10000. When the UID of the calling party process is smaller than 10000, determining that the calling party process is a daemon; and when the UID of the calling party process is more than or equal to 10000, determining that the calling party process is a process of the application program.
In addition, the identification information of the caller process may further include: the PID (Process Identifier ), which is the identity of each process, is automatically assigned to a process by the system as soon as the program starts running. In this embodiment, it may be determined whether the caller process is a daemon according to the scope of UID, but to obtain more information of the daemon, such as the name of the daemon, the path, etc., identification by PID is required. Because different daemons UID may be the same, but PID is unique.
S12, determining that the calling party process is a daemon process, and judging whether the calling party process is in a preset white list or not.
Specifically, the preset whitelist includes a set of known, secure daemons.
Illustratively, the daemon in the preset whitelist may be a system daemon, e.g., syslogd, login, crond, at, etc.; but may also be a web daemon such as sendmail, httpd, xinetd, etc.; but may also be a daemon that is independently started, e.g., httpd, named, xinetd, etc.; but also a passive daemon such as telnet, finger, ktalk, etc.
In some embodiments, if the caller process is within a preset whitelist, the caller process is allowed to complete the call operation.
Specifically, if the calling party process is a daemon process native to the Linux system or a daemon process native to the android system, the daemon process is allowed to complete the corresponding calling operation without throwing an exception. If the caller process is not within the preset whitelist, step S13 is performed.
S13, determining that the calling party process is not in a preset white list, and popping up an authentication interface.
The display information of the authentication interface comprises: the name of the caller process and the directory path of the caller process.
Specifically, the authentication interface is used for providing an input window for selecting the authority of the calling process for the user, and the user judges whether the calling process is safe and credible according to the name of the calling process and the directory path of the calling process displayed by the authentication interface, so that the authority of the calling process is selected.
Illustratively, the daemon's authentication interface defaults to null, and a record is generated when a daemon has actual calling behavior. One daemon corresponds to multiple rights, e.g., daemon 1 corresponds to rights: acquiring current address information, acquiring user contact information, acquiring storage space and the like. Referring to FIG. 2, FIG. 2 is a schematic diagram of an authentication interface of a daemon process. The authentication interface of the daemon is similar to the rights management interface of the application program, but the daemon and the daemon are different, and the rights management interface of the application program has clear icons, and each icon corresponds to a different name. While the authentication interfaces of daemons are all default icons that are distinguished by different process names, e.g., process 1, process 2, process 3, etc.
S14, responding to the authority selection behavior of the user on the authentication interface, and executing corresponding process calling operation.
Wherein the rights selection actions include: allowing calls and rejecting calls.
Specifically, when the authority of the user at the authentication interface is selected as permission to be invoked, the daemon executes corresponding process invoking operation; when the authority of the user at the authentication interface is selected as refusing to be invoked, the daemon cannot execute the corresponding process invoking operation.
The method comprises the steps of firstly determining whether a calling party process is a daemon or not, judging whether the calling party process is in a preset white list or not after determining that the calling party process is the daemon, popping up an authentication interface when determining that the calling party process is not in the preset white list, and executing corresponding process calling operation in response to authority selection behaviors of a user at the authentication interface. After determining that the calling party process is the daemon process, judging whether the calling party process is in a preset white list or not, and if the calling party process is not in the preset white list, popping up an authentication interface to enable a user to determine whether the calling party process is safe and reliable according to the name of the calling party process in the authentication interface and the directory path of the calling party process, and finally executing corresponding process calling operation based on authority selection behavior of the user in the authentication interface, so that authentication of the daemon process is realized.
In some embodiments, after step S14 is performed on the basis of fig. 1, referring to fig. 3, the following step S15 may also be performed:
and S15, storing the attribute information of the calling party process into a permission database.
The process attribute information of the calling party process comprises: the method comprises the steps of MD5 value of a calling party process file, name of the calling party process, path of the calling party process, authority of the calling party process and authority authorization state of the calling party process. The permission database is used for storing the process attribute information of the calling party process as the daemon.
Specifically, MD5 (Message-Digest Algorithm, fifth edition) is a widely used cryptographic hash function that can generate a 128-bit hash value to ensure complete consistency of information transmission. In this embodiment, the MD5 value of the daemon file is used as the ID used when the daemon performs rights saving.
Illustratively, the permissions of the caller process may include, but are not limited to: acquiring user contact information, acquiring user album information, acquiring user storage rights and the like. The authority authorization status of the caller process may include, but is not limited to: allow, reject, allow only when used. The name of the caller process may be: vendor.qti.hardware.qteecnector@1.0-service.
In some embodiments, when the target daemon executes the corresponding calling operation, acquiring the authority authorization state of the target daemon according to the authority database; and determining whether to execute corresponding process calling operation according to the authority authorization state of the target daemon.
In particular, the rights database may persist the user's selection behavior. When the related rights are called again by the calling party process next time, the rights authorization state of the related rights of the calling party process can be searched from the rights database. And determining whether to execute the corresponding process calling operation according to the authority authorization state of the calling process.
In some embodiments, a UID of the caller process is obtained; if the UID of the calling party process is a first preset value, replacing the UID of the calling party process with a second preset value of a transfer layer; when an authorization request sent by a process corresponding to the UID of the second preset value is received, the PID of the calling party process is obtained; and determining whether the calling process is in a preset white list according to the PID of the calling process.
Specifically, the authentication mode of the process of the application program is that the UID of the calling party process is obtained as a parameter in the function of the called party process through a binder public interface, and the UID and the specific authority are transmitted to the authority management service for authentication. Thus, it may also be determined whether the caller process is within a preset whitelist by:
an application program with a UID of a fixed value is installed in the system by default, the UID of the application program can be 55555, the application program is used as a transit layer, the UID of a calling party process is obtained in a function of a process of the application program through a binder public interface, for example, the UID of the calling party process is 0, the UID of the calling party process is modified to 55555, when an authorization request sent by the application program with the UID of 55555 is received, the PID of the calling party process is obtained, and whether the PID of the calling party process is in a preset white list or not is further determined according to the PID of the calling party process. By means of the mode of uniformly replacing UIDs, the determination efficiency of daemons can be improved.
By applying the embodiment of the application, firstly, whether the calling party process is a daemon process is determined, after the calling party process is determined to be the daemon process, whether the calling party process is in a preset white list is judged, when the calling party process is determined not to be in the preset white list, an authentication interface is popped up, and corresponding process calling operation is executed in response to authority selection behaviors of a user at the authentication interface. After determining that the calling party process is the daemon process, judging whether the calling party process is in a preset white list or not, and if the calling party process is not in the preset white list, popping up an authentication interface to enable a user to determine whether the calling party process is safe and reliable according to the name of the calling party process in the authentication interface and the directory path of the calling party process, and finally executing corresponding process calling operation based on authority selection behavior of the user in the authentication interface, so that authentication of the daemon process is realized.
In one embodiment, as shown in fig. 4, there is provided an authentication apparatus 400 of a daemon, comprising:
a determining module 410, configured to determine whether the calling process is a daemon process;
a judging module 420, configured to determine that the calling process is a daemon process, and judge whether the calling process is in a preset whitelist;
a selection module 430, configured to determine that the caller process is not in a preset whitelist, and pop up an authentication interface; the display information of the authentication interface comprises: the name of each daemon and the directory path of each daemon;
and the execution module 440 is used for responding to the authority selection action of the user on the authentication interface and executing corresponding process calling operation.
As an alternative implementation manner of the embodiment of the present application, the determining module 410 includes:
the acquisition unit is used for acquiring the identification information of the calling party process; the identification information of the calling party process comprises: a user identifier UID;
and the determining unit is used for determining whether the calling party process is a daemon according to the identification information of the calling party process.
As an optional implementation manner of the embodiment of the present application, the determining unit is specifically configured to:
if the user identifier of the calling party process is smaller than a preset value, determining that the calling party process is a daemon;
and if the user identifier of the calling party process is larger than or equal to a preset value, determining that the calling party process is a process of the application program.
As an optional implementation manner of the embodiment of the present application, the determining module 420 is further configured to:
and if the calling party process is in the preset white list, allowing the calling party process to complete calling operation.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes:
the storage module is used for storing the attribute information of the calling party process into a permission database;
the process attribute information of the calling party process comprises: the method comprises the steps of MD5 value of a calling party process file, name of the calling party process, path of the calling party process, authority of the calling party process and authority authorization state of the calling party process.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes:
the state acquisition module is used for acquiring the authority authorization state of the target daemon according to the authority database;
and the processing module is used for determining whether to execute corresponding process calling operation according to the authority authorization state of the target daemon process.
As an optional implementation manner of the embodiment of the present application, the apparatus further includes an analysis module, where the analysis module is specifically configured to:
acquiring the UID of the calling party process;
if the UID of the calling party process is a first preset value, replacing the UID of the calling party process with a second preset value of a transfer layer;
when an authorization request sent by a process corresponding to the UID of the second preset value is received, the PID of the calling party process is obtained;
and determining whether the calling process is in a preset white list according to the PID of the calling process.
By applying the embodiment of the application, firstly, whether the calling party process is a daemon process is determined, after the calling party process is determined to be the daemon process, whether the calling party process is in a preset white list is judged, when the calling party process is determined not to be in the preset white list, an authentication interface is popped up, and corresponding process calling operation is executed in response to authority selection behaviors of a user at the authentication interface. After determining that the calling party process is the daemon process, judging whether the calling party process is in a preset white list or not, and if the calling party process is not in the preset white list, popping up an authentication interface to enable a user to determine whether the calling party process is safe and reliable according to the name of the calling party process in the authentication interface and the directory path of the calling party process, and finally executing corresponding process calling operation based on authority selection behavior of the user in the authentication interface, so that authentication of the daemon process is realized.
For specific limitations of the authentication means of the daemon, reference may be made to the above limitation of the authentication method of the daemon, which is not repeated here. The modules in the authentication device of the daemon may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be stored in software in a processor of the electronic device, so that the processor may call and execute operations corresponding to the above modules.
The embodiment of the application also provides an electronic device, and fig. 5 is a schematic structural diagram of the electronic device provided in the embodiment of the application. As shown in fig. 5, the electronic device provided in this embodiment includes: a memory 51 and a processor 52, the memory 51 for storing a computer program; the processor 52 is configured to perform the steps performed by any of the daemon authentication methods provided by the method embodiments described above when the computer program is invoked. The electronic device comprises a processor, a memory, a communication interface, a display screen and an input device which are connected through a system bus. Wherein the processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The computer program, when executed by a processor, implements a daemon authentication method. The display screen of the electronic equipment can be a liquid crystal display screen or an electronic ink display screen, the input device of the electronic equipment can be a touch layer covered on the display screen, can also be a key, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.
It will be appreciated by those skilled in the art that the structure shown in fig. 5 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the computer device to which the present application is applied, and that a particular electronic device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, the daemon authentication apparatus provided herein may be implemented in the form of a computer program that may run on an electronic device as shown in fig. 4. The memory of the electronic device may store therein various program modules constituting authentication means of the daemon for the client type of the electronic device, such as the determining module 410, the judging module 420, the selecting module 430 and the executing module 440 shown in fig. 4. The computer program of each program module causes the processor to execute the steps in the authentication method of the daemon of the electronic device of each embodiment of the present application described in the present specification.
The embodiment of the application also provides a computer readable storage medium, and a computer program is stored on the computer readable storage medium, and when the computer program is executed by a processor, the authentication method of the daemon provided by the embodiment of the method is realized.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied therein.
The processor may be a central decision unit (CentralProcessingUnit, CPU), but may also be other general purpose processors, digital signal processors (DigitalSignalProcessor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash memory (flashRAM). Memory is an example of a computer-readable medium.
Computer readable media include both non-transitory and non-transitory, removable and non-removable storage media. Storage media may embody any method or technology for storage of information, which may be computer readable instructions, data structures, program modules, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transshipment) such as modulated data signals and carrier waves.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing is merely a specific embodiment of the disclosure to enable one skilled in the art to understand or practice the disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown and described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A method of authenticating a daemon process, the method comprising:
determining whether the calling party process is a daemon process;
determining that the calling party process is a daemon process, and judging whether the calling party process is in a preset white list or not;
determining that the calling party process is not in a preset white list, and popping up an authentication interface; the display information of the authentication interface comprises: the name of the caller process and the directory path of the caller process;
and responding to the authority selection behavior of the user on the authentication interface, and executing corresponding process calling operation.
2. The method of claim 1, wherein determining whether the caller process is a daemon comprises:
acquiring identification information of a calling party process; the identification information of the calling party process comprises: a user identifier UID;
and determining whether the calling process is a daemon according to the identification information of the calling process.
3. The method of claim 2, wherein the determining whether the caller process is a daemon based on the identification information of the caller process comprises:
if the user identifier of the calling party process is smaller than a preset value, determining that the calling party process is a daemon;
and if the user identifier of the calling party process is larger than or equal to a preset value, determining that the calling party process is a process of the application program.
4. The method of claim 1, wherein the determining whether the caller process is within a preset whitelist further comprises:
and if the calling party process is in the preset white list, allowing the calling party process to complete calling operation.
5. The method of claim 1, wherein after performing the corresponding process call operation in response to the user's rights selection behavior, the method further comprises:
storing attribute information of the calling party process into a permission database;
the process attribute information of the calling party process comprises: the method comprises the steps of MD5 value of a calling party process file, name of the calling party process, path of the calling party process, authority of the calling party process and authority authorization state of the calling party process.
6. The method of claim 5, wherein the method further comprises:
acquiring the authority authorization state of the target daemon according to the authority database;
and determining whether to execute corresponding process calling operation according to the authority authorization state of the target daemon.
7. The method of claim 1, wherein said determining whether the caller process is within a preset whitelist further comprises:
acquiring the UID of the calling party process;
if the UID of the calling party process is a first preset value, replacing the UID of the calling party process with a second preset value of a transfer layer;
when an authorization request sent by a process corresponding to the UID of the second preset value is received, the PID of the calling party process is obtained;
and determining whether the calling process is in a preset white list according to the PID of the calling process.
8. An authentication device for daemon processes, comprising:
the determining module is used for determining whether the calling party process is a daemon process or not;
the judging module is used for determining that the calling party process is a daemon process and judging whether the calling party process is in a preset white list or not;
the selection module is used for determining that the calling party process is not in a preset white list and popping up an authentication interface; the display information of the authentication interface comprises: the name of each daemon and the directory path of each daemon;
and the execution module is used for responding to the authority selection behavior of the user on the authentication interface and executing corresponding process calling operation.
9. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the daemon authentication method of any of claims 1 to 7 when executing the computer program.
10. A computer readable storage medium, having stored thereon a computer program which, when executed by a processor, implements a method of authenticating a daemon according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310328149.1A CN116432166A (en) | 2023-03-27 | 2023-03-27 | Authentication method and device of daemon, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310328149.1A CN116432166A (en) | 2023-03-27 | 2023-03-27 | Authentication method and device of daemon, electronic equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116432166A true CN116432166A (en) | 2023-07-14 |
Family
ID=87079008
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310328149.1A Pending CN116432166A (en) | 2023-03-27 | 2023-03-27 | Authentication method and device of daemon, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116432166A (en) |
-
2023
- 2023-03-27 CN CN202310328149.1A patent/CN116432166A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6248153B2 (en) | Activate trust level | |
| US10528735B2 (en) | Malicious code protection for computer systems based on process modification | |
| US11757937B2 (en) | Enabling webapp security through containerization | |
| US9509697B1 (en) | Systems and methods for authorizing attempts to access shared libraries | |
| CN110363026B (en) | File operation method, device, equipment, system and computer readable storage medium | |
| US20060212939A1 (en) | Virtualization of software configuration registers of the TPM cryptographic processor | |
| CN107292176B (en) | Method and system for accessing a trusted platform module of a computing device | |
| US11706220B2 (en) | Securing application behavior in serverless computing | |
| US20150235030A1 (en) | Method for Processing UEFI Protocols and System Therefor | |
| CN111931154B (en) | Service processing method, device and equipment based on digital certificate | |
| US8677508B2 (en) | Confidential information leakage prevention system, confidential information leakage prevention method and confidential information leakage prevention program | |
| US10592661B2 (en) | Package processing | |
| US10489582B1 (en) | Firmware security vulnerability verification service | |
| US20170192805A1 (en) | Virtualizing integrated calls to provide access to resources in a virtual namespace | |
| US10592660B2 (en) | Capability access management | |
| US20170300692A1 (en) | Hardware Hardened Advanced Threat Protection | |
| CN111753270A (en) | Application program login verification method, device, equipment and storage medium | |
| US10789518B2 (en) | Barcode-based enrollment of devices with a management service | |
| CN116432166A (en) | Authentication method and device of daemon, electronic equipment and readable storage medium | |
| CN107392010B (en) | Root operation execution method and device, terminal equipment and storage medium | |
| US11734429B1 (en) | Secure bios-enabled passthrough system | |
| KR20200048676A (en) | Method for managing data based on blockchain, apparatus and system for the same | |
| US10757095B1 (en) | Unix password replication to a set of computers | |
| US20240265084A1 (en) | Selectively validating and enabling resource enablers of a secure workspace | |
| US11343252B2 (en) | Kernel level application data protection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |