Sponsored Content
Special Forums Cybersecurity Attacking Potential of sh-scripts Post 302508520 by disaster on Monday 28th of March 2011 11:18:35 AM
Old 03-28-2011
Thanks for the answer, but you misunderstood me.
I assumed that all form of bringing executable code in the system is not possible (which is done via signature checking in the kernel), except the sh script code (and probably techniques like buffer overflow hacking which I'm also not competent at Smilie)
So basically all the user can do is to execute programs that are already on the system. Changing those in the system will cause them to fail to execute.

Because if I understand you right you mean he would build is own executable by copying it from different locations and/or writing it new. Such executables would be hindered from execution by the kernel
 

3 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Potential new user of Unix

Hi all, Complete and utter virgin Unix person here (I don't even have the OS yet) As I'm doing a "looking into it" kinda thing before I move from MS I hope my questions are not inappropriate. 1. Should I get some kind off anti virus software. I know Unix is pretty good for not getting them... (2 Replies)
Discussion started by: dhula
2 Replies

2. AIX

how to handle potential file contention

I need to change how a posting procedure currently works in order to improve load balancing but I am hitting a potential file contention problem that I was wondering if someone here could assist me with... In a directory called FilePool I would have a bunch of files that are constantly coming in... (3 Replies)
Discussion started by: philplasma
3 Replies

3. HP-UX

Potential file system contention on directory

We have an 8-processor Itanium system running HP-UX 11.23 connected to shared SAN discs. We have an application that creates files (about 10) in a specific directory. When the application terminates, these files are removed (unlink) and a few others are updated. The directory contains... (8 Replies)
Discussion started by: FDesrochers
8 Replies
setkey(3C)						   Standard C Library Functions 						setkey(3C)

NAME
setkey - set encoding key SYNOPSIS
#include <stdlib.h> void setkey(const char *key); DESCRIPTION
The setkey() function provides (rather primitive) access to the hashing algorithm employed by the crypt(3C) function. The argument of setkey() is an array of length 64 bytes containing only the bytes with numerical value of 0 and 1. If this string is divided into groups of 8, the low-order bit in each group is ignored; this gives a 56-bit key which is used by the algorithm. This is the key that will be used with the algorithm to encode a string block passed to encrypt(3C). RETURN VALUES
No values are returned. ERRORS
The setkey() function will fail if: ENOSYS The functionality is not supported on this implementation. USAGE
In some environments, decoding may not be implemented. This is related to U.S. Government restrictions on encryption and decryption rou- tines: the DES decryption algorithm cannot be exported outside the U.S.A. Historical practice has been to ship a different version of the encryption library without the decryption feature in the routines supplied. Thus the exported version of encrypt() does encoding but not decoding. Because setkey() does not return a value, applications wishing to check for errors should set errno to 0, call setkey(), then test errno and, if it is non-zero, assume an error has occurred. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Standard | +-----------------------------+-----------------------------+ |MT-Level |Safe | +-----------------------------+-----------------------------+ SEE ALSO
crypt(3C), encrypt(3C), attributes(5), standards(5) SunOS 5.11 14 Aug 2002 setkey(3C)
All times are GMT -4. The time now is 08:45 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy