“Security through obscurity” may be a catchy phrase, but it’s not the only thing that’s catching among Windows users.
The expression is intended to suggest that proprietary software is more secure by virtue of its closed nature. If hackers can’t see the code, then it’s harder for them to create exploits for it–or so the thinking goes.
Unfortunately for Windows users, that’s just not true–as evidenced by the never-ending parade of patches coming out of Redmond. In fact, one of Linux’s many advantages over Windows is that it is more secure–much more. For small businesses and other organizations without a dedicated staff of security experts, that benefit can be particularly critical.
Five key factors underlie Linux’s superior security:
1. Privileges
Linux systems are by no means infallible, but one of their key advantages lies in the way account privileges are assigned. In Windows, users are generally given administrator access by default, which means they pretty much have access to everything on the system, even its most crucial parts. So, then, do viruses. It’s like giving terrorists high-level government positions.
With Linux, on the other hand, users do not usually have such “root” privileges; rather, they’re typically given lower-level accounts. What that means is that even if a Linux system is compromised, the virus won’t have the root access it would need to do damage systemwide; more likely, just the user’s local files and programs would be affected. That can make the difference between a minor annoyance and a major catastrophe in any business setting.
Social Engineering
Viruses and worms often spread by convincing computer users to do something they shouldn’t, like open attachments that carry viruses and worms. This is called social engineering, and it’s all too easy on Windows systems. Just send out an e-mail with a malicious attachment and a subject line like, “Check out these adorable puppies!”–or the porn equivalent–and some proportion of users is bound to click without thinking. The result? An open door for the attached malware, with potentially disastrous consequences organizationwide.
Thanks to the fact that most Linux users don’t have root access, however, it’s much harder to accomplish any real damage on a Linux system by getting them to do something foolish. Before any real damage could occur, a Linux user would have to read the e-mail, save the attachment, give it executable permissions and then run the executable. Not very likely, in other words.
3. The Monoculture Effect
However you want to argue the exact numbers, there’s no doubt that Microsoft Windows still dominates most of the computing world. In the realm of e-mail, so too do Outlook and Outlook Express. And therein lies a problem: It’s essentially a monoculture, which is no better in technology than it is in the natural world. Just as genetic diversity is a good thing in the natural world because it minimizes the deleterious effects of a deadly virus, so a diversity of computing environments helps protect users.
Fortunately, a diversity of environments is yet another benefit that Linux offers. There’sUbuntu, there’s Debian, there’s fedora and there are many other distributions. There are also many shells, many packaging systems, and many mail clients; Linux even runs on many architectures beyond just Intel. So, whereas a virus can be targeted squarely at Windows users, since they all use pretty much the same technology, reaching more than a small faction of Linux users is much more difficult. Who wouldn’t want to give their company that extra layer of assurance?
4-Audience Size
Hand-in-hand with this monoculture effect comes the not particularly surprising fact that the majority of viruses target Windows, and the desktops in your organization are no exception. Millions of people all using the same software make an attractive target formalicious attacks.
5. How Many Eyeballs
“Linus’ Law”–named for Linus Torvalds, the creator of Linux–holds that, “given enough eyeballs, all bugs are shallow.” What that means is that the larger the group of developers and testers working on a set of code, the more likely any flaws will be caught and fixed quickly. This, in other words, is essentially the polar opposite of the “security through obscurity” argument.
With Windows, it’s a limited set of paid developers who are trying to find problems in the code. They adhere to their own set timetables, and they don’t generally tell anyone about the problems until they’ve already created a solution, leaving the door open to exploits until that happens. Not a very comforting thought for the businesses that depend on that technology.
In the Linux world, on the other hand, countless users can see the code at any time, making it more likely that someone will find a flaw sooner rather than later. Not only that, but users can even fix problems themselves. Microsoft may tout its large team of paid developers, but it’s unlikely that team can compare with a global base of Linux user-developers around the globe. Security can only benefit through all those extra “eyeballs.”
Once again, none of this is to say that Linux is impervious; no operating system is. And there are definitely steps Linux users should take to make their systems as secure as possible, such as enabling a firewall, minimizing the use of root privileges, and keeping the system up to date. For extra peace of mind there are also virus scanners available for Linux, including ClamAV. These are particularly good measures for small businesses, which likely have more at stake than individual users do.
It’s also worth noting that security firm Secunia recently declared that Apple products have more security vulnerabilities than any others–including Microsoft’s.
Either way, however, when it comes to security, there’s no doubt that Linux users have a lot less to worry about.

A LINUX socket (inter-process communication socket) is a data communications endpoint for exchanging data between processes WHICH allow one process to communicate with another whether it is local on the same computer system or remote over the network. Many other higher level protocols are built upon sockets technology.
Sockets utilize the following standard protocols:

Protocol Description
IP Internet Protocol provides network routing using IP addressing eg 192.168.1.204
UDP User Datagram Protocol – IP with ports to distinguish among processes running on same host. No data verification.
TCP Transmission Control Protocol – IP with ports to distinguish among processes running on same host.Connection oriented, stream
transfer, full duplex, reliable with data verification.

Typically one configures a socket server to which a socket client may attach and communicate.
Create the socket instance.
IN THIS THE STEPS ARE DESCRIBED HOW WE CREATE SOCKET & HOW SERVER AND CLINT INTERACT WITH EACH OTHER.
1-Socket function prototype:
int sockfd = socket(int socket_family, int socket_type, int protocol)
discription: Choose socket communications family/domain
according to the communication within same host or over the network we choose the family as AF_UNIX,OR AF_INET ACCORDINGLY.

Choose socket type:

TCP: SOCK_STREAM for connection oriented services using tcp protocol.
UDP: SOCK_DGRAM for connectionless services using UDP protocol.

Choose socket protocol: (See /etc/protocols)
for AF_UNIX & AF_INET or Internet Protocol (IP): 0 or IPPROTO_IP
for ICMP: 1
2-Configure the socket as a client or server:
Socket Server            Socket Client
socket()                      socket()
bind()
listen()
accept()                        connect()
recv()/send()            recv()/send()
close() close()
This is specific to whether the application is a socket client or a socket server.
above all calls are listed which we use in socket as server & clint configuration.
the detail discription of calls are as…
Socket server:
bind(): bind the socket to a local socket address. This assigns a name to the socket.Function prototype:
int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen);
Bind arguments:
int sockfd: Socket file descriptor. Returned by call to “socket”.
struct sockaddr: Socket information structure
socklen_t addrlen: Size of structure
Returns 0: Sucess, -1: Failure and errno may be set.
listen(): listen for connections on a socket created with “socket()” and “bind()” and accept incoming connections. This is used for TCP and not UDP. Zero is returned on success.Function prototype:
int listen(int s, int backlog);
Listen arguments:
int s: Socket file descriptor. Returned by call to “socket”. Identifies a bound but unconnected socket.
int backlog: Set maximum length of the queue of pending connections for the listening socket. A reasonable value is 10. Actual maximum permissible: SOMAXCONN .
accept(): accept a connection on a socket. Accept the first connection request on the queue of pending connections, create a new connected socket with mostly the same properties as defined by the call to “socket()”, and allocate a new file descriptor for the socket, which is returned. The newly created socket is no longer in the listening state. Note this call blocks until a client connects.
Function prototype:
int accept(int s, struct sockaddr *addr, socklen_t *addrlen);
Accept arguments:
int s: Socket file descriptor. Returned by call to “socket”.
struct sockaddr *addr: Pointer to a sockaddr structure. This structure is filled in with the address of the connecting entity.
socklen_t *addrlen: initially contains the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. When addr is NULL nothing is filled in.
Returns:
Success: non-negative integer, which is a descriptor of the accepted socket. Argument “addrlen” will have a return value.
Fail: -1, errno may be set

Socket client:
connect(): initiate a connection with a remote entity on a socket. Zero is returned on success. Support both TCP (SOCK_STREAM) and UDP (SOCK_DGRAM). For SOCK_STREAM, an actual connection is made. For SOCK_DGRAM the address is the address to which datagrams are sent and received.
Connect function prototype:
int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen);
Connect arguments: (Same as server’s bind() arguments)
int sockfd: Socket file descriptor. Returned by call to “socket”.
struct sockaddr: Socket information structure
socklen_t addrlen: Size of structure
Returns 0: Sucess, -1: Failure and errno may be set.
Zero is returned upon success and on error, -1 and errno is set appropriately.

here description of sockaddr_in data structure that how we name & provide address to socket.

socketInfo.sin_family = AF_INET;
// Use any address available to the system. This is a typical configuration for a server.
// Note that this is where the socket client and socket server differ.
// A socket client will specify the server address to connect to.
socketInfo.sin_addr.s_addr = htonl(“ip addd”); // Translate long integer to network byte order.
socketInfo.sin_port = htons(portNumber); // Set port number

so this is all about socket programming in brief….

                                                                           SUBMITTED TO:  Mr. PRAVJOT SINGH                                  LINUX DEVICE DRIVERS  

v  ARTICLE ON CHARACTER DRIVER:

THIS  ARTICLE   IS ALL ABOUT  TO  THE CONCEPTS  THAT  I HAVE  LEARNED  AND  MAINLY  CONCERNED TO THE WORK  WHATEVER  I HAVE PERFORMED  IN THE PROJECT  REGARDING ASSIGNMENT IN ORDER  TO  SUCCESSFUL  COMPLETION OF TRAINING.

v  INTRODUCTION OF CHARACTER DRIVER:

AS THE  NAME  SUGGESTS  ,THE DEVICE -DRIVER  PROVIDES THE MECHANISM  TO  DRIVE THE  HARDWARE(DEVICE)  ACCORDING  TO  THE  APPLICTION.THE TYPE & CATEGORY   OF THE DRIVER  IS DEPENDENT  ON  THE  TYPE &  REQUIREMENT OF APPLICATION  WHICH  WEAREUSING. WHICH MEANS TOSAYTHAT  TO ACCESS  THE  PENDRIVE WE NEED USB  DRIVER  ,FOR BTLUETOOTH WE WE NEED BT DRIVER & FOR  MEDIA  PLAYER  WE  NEED  A  SEPRATE ONE.  DIFFERENT TYPES OF APPLICATION  REQUIRES   DIFFERENT  TYPE  OF  DRIVERS.

CHARACTER DRIVER WORKS FOR CHARACTER DEVICES   WHICH  CAN BE ACCESSED AS STREAM OF BYTES. SUCH DRIVER USUALLY IMPLEMENTS OPEN, WRITE,  READ  &  CLOSE  SYSTEM  CALLS.

I think One of the good features of Linux is the ability to extend at runtime the set of features offered by the kernel. This means that you can add modules to the kernel (and remove modules as well) while the system is up and running. The need of using device drivers is to increase the functionality of kernel . Each piece of code that can be added to the kernel at runtime is called a module. Each module is made up of piece of codes that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

Currently I am working on character driver & its practical implementation. In this article I am going to discuss what i know about character driver briefly.

Now as I have to make my driver capable of directly handshake-able with the kernel so it was essential to work in kernel space instead of user space ,so i have to use the kernel libraries(like kernel.h, init.h ,fs.h etc..) instead of glibc libraries(like stdio.h,stdlib.h,fcntl.h etc…).

v  HOW   TO   IMPLEMENT?

• I AM GOING TO DESCRIBE THE BASIC  STEPS WHICH  I  HAVE  FOLLOWED WHILE  IMPLEMENTING CHARACTER DRIVER:

–     I started to write the program  using two predefined macros named as module_init (entry_function) and module_exit(exit_function) as entrance point as main() in user space and exit point respectively.In which I have written my own start &  end function. So after executing module_init execution will start from my function where I have to specify the major number and name of our driver, capacity to handle maximum number of device at a time and maximum memory of the driver. The major number identifies the driver associated with the device. I am firstly allocating major number to my driver which is basically a highest possible integer value between 0 to 255 by which our driver will be known in the kernel like other device drivers as stored in /proc/devices file .We can select major number for our driver from previously mentioned path but generally we privilege kernel to select major number because kernel will allocate it dynamically .This can be done with the register_chrdev_region() function call defined in fs.h  which is in kernel library .In current scenario register_allok_chardev_region is in trend to do the errlier mentioned task .This will give the result of 32 bit(12 + 20 bit) at the address as give in first argument of call. After that I have used the first 12 bit i.e major number but i specify my own minor number generally 0 to upward in MKDEV() macro defined in kdev_t.h. After that I have allocated memory to sculldev structure(user defined structure that contain all information of the driver)) & separately initialized all its members as sculldev initialization function .Now used the cdev_init() and cdev_add() to initialize and add the cdev structure for our device which will contains the device specifications. Now I have written separate functions for each ( to create scullQsets structures, create q-sets structures, create quantums)& called these functions from write & read functions of driver modules to perform the desired operations in device.

In order to perform various operations like open, write, read, lseek and close file I have written an application in  user space & mapped it similar kind if file operations (open, write read, llseek, release)that is in my driver program .So i have mapped these system calls in struct file_operations structure with my respective open,write,read,lseek and close functions according to prototype defined in <fs.h> kernel header file that will now handles the application calls instead of drivers of the OS.

But Before doing anything we have to map our allocated memory with the device memory this is done in the open function of driver with

container_of(ptr, type, member) in which first argument is pointer to i_cdev member of struct inode,2nd argument is user defined structure which contains pointer to struct cdev and third argument is pointer to struct cdev.Actually struct cdev is actual representation of the device. Now return of container_of will be starting address of mapped memory that we will use to read and write on device and i store this address in the private_data of the struct file structure defined in fs.h library.

After doing this now i have made my read, write and lseek function compatible with the almost all type of requests from application.In this write function will store the written data in own quantums when write request comes and give back that data according to the read request of application.I have also handled the single multithreaded application.

Now to test this driver we have to compile and insert our module in running kernel dynamically. This is done with command insmod ./modules/program name(without .c).ko  & Compilation of the file should be by Makefile. After completion of work (successful insertion & execution of task) we have to remove our module this is done by command rmmod  program name(without .c).

If every step is correct & written in proper manner then  program will run & it will give desired result otherwise kernel will be crashed.

REMARKS: THERE MAY BE  POSSIBILITY OF ERROR IN SYNTEX, SENTENCES,ARGUMENTS (& SOME-WHAT IN CONCEPTS ALSO ). SO ANY COMMENT, CORRECTION, SUGGESTION  IS CORDIONLY INVITED.

REGARD’S

RANA BRIJENDRA SINGH